About the same idea, see also GUI and Alternate GUI (two posts formerly in sequence, now separated by the magic of primes 2)

The latex command frequently generates very bad output. So, in general, I find much easier to type the formulas  from scratch (with my text editor) than trying to patch Maple LaTeX code into something decent. 

Complaints about this bad code has been a kind of "tradition" in this forum, see e.g. the wish lists for every release like that for Maple 12. And some people got so frustrated that wrote their own LaTeX exporting routines. See e.g.:

Maple Expressions To LaTeX Converter

Better LaTeX Output From Maple

I am more conservative than you, and I keep using the Classic GUI with Maple 14. In particular, it has no problem by opening the Maple 12 Classic GUI mws worksheets, so I find no good reason to loose time translating them into Standard GUI mws or mw format files. In particular as the latter formats are much more bulky, in most cases they do not offer me any other advantage, and moreover, the Standard GUI is very awkward to my taste.

@alex_01 

Actually, only a fraction of the improvements become documented. And from them, the features actively marketed are a smaller fraction yet, usually those of a secondary importance from my viewpoint. Search also e.g. for Axel Vogt comments about this issue after every release as here (a classic). 

@Joe Riel Fine, I get an lprinted output:

F:=
proc()
local p,P,f;
    p := proc(x) RealDomain:-sin(x) end proc;
    P := ToInert(eval(p));
    f := indets(P, 'specfunc(anything,_Inert_FUNCTION)')[1];
 lprint(FromInert(f));
end proc:
F();

RealDomain:-sin(args[1])

But now, the object thus lprinted seems to be a sequence with 0 operands:

whattype(F());

RealDomain:-sin(args[1])
                            exprseq

F()[1];

RealDomain:-sin(args[1])
Error, invalid subscript selector

nops([F()]);

RealDomain:-sin(args[1])
                               0

It sounds strange.

@Joe Riel Interesting, but it opens more questions.

What is the object, assigned to f,  whose inert expression is:

proc()
local p,P,f;
    p := proc(x) RealDomain:-sin(x) end proc;
    P := ToInert(eval(p));
    f := indets(P, 'specfunc(anything,_Inert_FUNCTION)')[1];
end proc();

_Inert_FUNCTION(_Inert_MEMBER(_Inert_ASSIGNEDNAME("RealDomain", 
  "MODULE", _Inert_ATTRIBUTE(_Inert_EXPSEQ(_Inert_NAME(
  "protected", _Inert_ATTRIBUTE(_Inert_NAME("protected"))), 
  _Inert_NAME("_syslib")))), _Inert_NAME("sin")), 
  _Inert_EXPSEQ(_Inert_PARAM(1)))

but whose active form cannot be "lprinted"?:

proc()
local p,P,f;
    p := proc(x) RealDomain:-sin(x) end proc;
    P := ToInert(eval(p));
    f := indets(P, 'specfunc(anything,_Inert_FUNCTION)')[1];
 FromInert(f):lprint(%);
end proc();

Error, (in unknown) invalid keyword expression

  And nevertheless, its 0-th operand lprints as RealDomain:-sin and has type procedure:

proc()
local p,P,f;
    p := proc(x) RealDomain:-sin(x) end proc;
    P := ToInert(eval(p));
    f := indets(P, 'specfunc(anything,_Inert_FUNCTION)')[1];
    f := op(0,FromInert(f)):
lprint(%);
end proc();
whattype(%);

RealDomain:-sin
                           procedure

So, in short, it seems like the module export can be matched by subs if the name is already assigned a procedure, but not by a name not yet assigned. If so, I wonder whether this is intended design or a weakness. Indeed, better documentation is needed.

@Robert Israel 

It seems that it is a general "feature" with module exported names. Cf.:

q:=proc (a) sin(a) end proc:
lprint(%);
subs(sin=pp,eval(q)):
lprint(%);

proc (a) sin(a) end proc
proc (a) pp(a) end proc

r:=proc (a) RealDomain:-sin(a) end proc:
lprint(%);
subs(RealDomain:-sin=pp,eval(r)):
lprint(%);

proc (a) RealDomain:-sin(a) end proc
proc (a) RealDomain:-sin(a) end proc

The inert forms are indeed different:

ToInert(eval(q));

_Inert_PROC(_Inert_PARAMSEQ(_Inert_NAME("a")), _Inert_LOCALSEQ(), 
  _Inert_OPTIONSEQ(), _Inert_EXPSEQ(), _Inert_STATSEQ(
  _Inert_FUNCTION(_Inert_ASSIGNEDNAME("sin", "PROC", 
  _Inert_ATTRIBUTE(_Inert_EXPSEQ(_Inert_NAME("protected", 
  _Inert_ATTRIBUTE(_Inert_NAME("protected"))), 
  _Inert_NAME("_syslib")))), _Inert_EXPSEQ(_Inert_PARAM(1)))), 
  _Inert_DESCRIPTIONSEQ(), _Inert_GLOBALSEQ(), 
  _Inert_LEXICALSEQ(), _Inert_EOP(_Inert_EXPSEQ()))

ToInert(eval(r));

_Inert_PROC(_Inert_PARAMSEQ(_Inert_NAME("a")), _Inert_LOCALSEQ(), 
  _Inert_OPTIONSEQ(), _Inert_EXPSEQ(), _Inert_STATSEQ(
  _Inert_FUNCTION(_Inert_MEMBER(_Inert_NAME("RealDomain"), 
  _Inert_ASSIGNEDNAME("sin", "PROC", _Inert_ATTRIBUTE(
  _Inert_EXPSEQ(_Inert_NAME("protected", 
  _Inert_ATTRIBUTE(_Inert_NAME("protected"))), 
  _Inert_NAME("_syslib"))))), _Inert_EXPSEQ(_Inert_PARAM(1)))), 
  _Inert_DESCRIPTIONSEQ(), _Inert_GLOBALSEQ(), 
  _Inert_LEXICALSEQ(), _Inert_EOP(_Inert_EXPSEQ()))

So, may be that the module exported name is not an operand that subs can syntactically match as an "ordinary" function name is. In particular the "ASSIGNEDNAME" does not seem to behave wrt subs as the "NAME" here:

subs(RealDomain=nn,sin=pp,eval(r)):
lprint(%);

proc (a) nn:-sin(a) end proc

@pagan 

I agree with your conjecture. Actually, this problem as well as several other oddities, make me think that the Standard GUI has actually a kind of parallel or secondary kernel, and problems occur when both kernels are not in "agreement".

@pagan 

I agree with your conjecture. Actually, this problem as well as several other oddities, make me think that the Standard GUI has actually a kind of parallel or secondary kernel, and problems occur when both kernels are not in "agreement".

@acer 

It is a bug introduced in Maple 14 Standard GUI. Output depends on whether the printlevel statement is in the same execution block. In the OP's example, if all these lines lay within the same execution block, output is produced:

printlevel:=100:
for i from 1 to 2 do
       for j from 1 to 2 do
             k:=i+j;
       end do;
  end do;

                               2
                               3
                               3
                               4

While if the printlevel:=100: line is in a block by itself, and the rest of the lines in a second block, no output is produced:

printlevel:=100:
for i from 1 to 2 do
       for j from 1 to 2 do
             k:=i+j;
       end do;
  end do;

This bug has already been reported.

@acer 

It is a bug introduced in Maple 14 Standard GUI. Output depends on whether the printlevel statement is in the same execution block. In the OP's example, if all these lines lay within the same execution block, output is produced:

printlevel:=100:
for i from 1 to 2 do
       for j from 1 to 2 do
             k:=i+j;
       end do;
  end do;

                               2
                               3
                               3
                               4

While if the printlevel:=100: line is in a block by itself, and the rest of the lines in a second block, no output is produced:

printlevel:=100:
for i from 1 to 2 do
       for j from 1 to 2 do
             k:=i+j;
       end do;
  end do;

This bug has already been reported.

The -i command line option works also in all the Windows interfaces.

The -i command line option works also in all the Windows interfaces.

And I would say that it is almost the same. I can launch e.g. Maple 14 Classic and Standard GUI from the Win XP cmd box, with these packages loaded, by:

C:\<path to Maple14>\bin.win\cwmaple.exe -c with(plots) -c with(LinearAlgebra

C:\<path to Maple14>\bin.win\maplew.exe -c with(plots) -c with(LinearAlgebra)

And I would say that it is almost the same. I can launch e.g. Maple 14 Classic and Standard GUI from the Win XP cmd box, with these packages loaded, by:

C:\<path to Maple14>\bin.win\cwmaple.exe -c with(plots) -c with(LinearAlgebra

C:\<path to Maple14>\bin.win\maplew.exe -c with(plots) -c with(LinearAlgebra)