I dislike the Standard GUI graphic debugger. I find it inconvenient and buggy. I prefer using the debugger in the CLI or the Classic GUI. Indeed, font options are available for them.

This is a known issue of the assume facility. As you have probably read already in this thread, this facility is actually a patch. So, it might be wiser to make things in another way, e.g by means of assuming (in turn, a kind of patch on assume). In general, it will make the assumptions during the evaluation of the expression and then undoes them, so that it should not further interfere with substitutions and the like:

H:=sqrt(a^2) assuming a>0;
                                     H := a
subs(a=b, H) assuming(a>0);
                                       b

The question, seems to me, when two or more integration methods return correct results, which should be returned. In this sense, there is a relationship with the issues raised in this thread. And the undocumented method _VERIFYALL, seems useful for this situation:

int(x^(-13/10), x=1/1000..1000,method=_VERIFYALL);
                                    9/10     1/10
                               10 10       10
                               --------- - ------
                                   3         3

Printing information shows that it takes as criterion the shortest of the computed results:

> infolevel[IntegrationTools]:=3:
> int(x^(-13/10), x=1/1000..1000,method=_VERIFYALL);
Definite Integration:   Will return a result only if all integrators agree.
Definite Integration:   Integrating expression on x=1/1000..1000
Definite Integration:   Using the integrators [distribution, piecewise, series, o, polynomial, ln, lookup, cook, ratpoly, elliptic, elliptictrig, meijergspecial, improper, asymptotic, ftoc, ftocms, meijerg, contour]
LookUp Integrator:   unable to find the specified integral in the table
Definite Integration:   Method meijergspecial succeeded.
Definite Integration:   Method ftoc succeeded.
Definite Integration:   Method ftocms succeeded.
Definite Integration:   Method meijerg succeeded.
Definite Integration:   Returning the shortest of the computed results.
                                    9/10     1/10
                               10 10       10
                               --------- - ------
                                   3         3

I would prefer the programmatic way, using a single procedure for any overscript, much like in TeX:

over:=proc(x,y)
nprintf("#mover(mi(%A),mo(%A))", x,y);
end proc:

over(x,"^");
over(x,"^");

About why. It seems like Maplesoft management is convinced that their TypeMK approach is better than TeX at typesetting. Meaning does not look like an issue, as only a few of TypeMK objects have a computational counterpart.

For the OP's request of obtaining, in pagan's notation, f from g, I would use the procedure dividend that I have already suggested, with the improvement of optional transformations for the numerator and denominator. And in the latter I would use a rule as follows:

dividend:=proc(ex,f:=numer(ex),t:=[expand,expand])
local n,d;
n:=t[1](numer(ex)/f):
d:=t[2](denom(ex)/f);
n/d;
end proc:

r:=a::nonunit(algebraic)+b::algebraic*f::function*(c::algebraic)^(1/2)=
a*(1+(b^2*c/a^2)^(1/2)*f):

s:=phi>0, Pi/2>phi, m>0, G>0, M>0:

dividend(g,numer(g),[x->x,(x->applyrule(r,x))@simplify@rationalize]) assuming s;
                                       2
                                      l
                 ---------------------------------------------
                        /    / 3  2  2         2\1/2         \
                      2 |    |m  G  M  + 2 En l |            |
                 M G m  |1 + |------------------|    cos(phi)|
                        |    |      3  2  2     |            |
                        \    \     m  M  G      /            /

Yes, you are correct. Support for such usage seems to be implemented in some areas of the system, but such support is patchy and undocumented. Just see a few examples in these threads:

Collecting-Names-And-Indexed-Symbols--A-Bug

Error-Message-When-Using-Indexed-Counter

Does-Maple-Need-To-Wait-A-Few-Seconds

So, in my opinion, the healthiest norm is avoiding indexed names altogether, when intended as subscripted names. As you can see, that "almost" is very doubtful!

@hajtmar 

I have just opened one of my Maple V Release 4 worksheets with Maple 12.02 Classic GUI on Win XP 32 and had no big problem: except for a pair of warnings it executes fine. I prefer normally opening the worksheet with the Maple version with which it was created. So, in particular, I do keep Maple V Release 4.00b installed.

May be that the simplest way is using the system default browser. I guess that all the different OSs/desktops have one nowadays. For instance, on my Win XP, the Standard GUI browser setting is "System Default", which is actually Firefox. The way it is handled can be seen in the cmd shell:

>assoc .html
.html=FirefoxHTML

>ftype FirefoxHTML
FirefoxHTML="C:\internet\Firefox\firefox.exe" -requestPending -osint -url "%1"

So that "executing" an html file at the cmd prompt opens it in Firefox. This information can also be extracted from the CLI:

> ssystem("assoc .html");
[0, ".html=FirefoxHTML
    "]

> ssystem("ftype FirefoxHTML");
[0, "FirefoxHTML="C:\internet\Firefox\firefox.exe" -requestPending -osint -ur\
    l "%1"
    "]

@Robert Israel 

I agree with your objections to the design of the geometry package. I find remarkable that this design has not been improved since, probably, the introduction of this package in Maple 4.3 ( ?updates,v43 ) over 22 years ago.

Aparently, this change of the default behavior would be easy. The differences of point coordinates like xA-xB are passed by checking routines like geometry:-checkline to geometry:-equalzero, which returns FAIL for such symbolic coordinates. And geometry:-checkline returns an error if for any of these differences FAIL is returned.

So, it seems an issue of bypassing this part of the conditional statement, commented out here, to make it work for symbolic coordinates:

kernelopts(opaquemodules=false):
with(geometry):
point(A, xA, yA):
point(B, xB, yB):

geometry:-checkline:=proc(u, v)
local signh, signv;
    if nargs <> 2 then error "wrong number of arguments" end if;
    signh := equalzero(u);
    signv := equalzero(v);
    if signh = true and signv = true then error "the line is not defined"
#    elif signh = FAIL and signv = true or signv = FAIL and signh = true or
#    signh = FAIL and signv = FAIL then
#        userinfo(1, 'hints',
#            "One of the following conditions must be satisfied ", u <> 0,
#            v <> 0);
#        error "not enough information: the line is not defined"
    end if
end proc:

line(AB, [A, B]);
                                       AB
detail(AB);
assume that the names of the horizontal and vertical axes are _x and _y, respectively
name of the object:  AB
    form of the object:  line2d
    equation of the line:  (yA-yB)*_x+(xB-xA)*_y+yB*xA-yA*xB = 0

IsOnLine(A, AB);
                                      true

The routine that actually makes the relevant transformation is `simplify/sqrt/fraction`. And the piece of code responsible for it is executed when there is a second argument, it may be symbolic or whatever, it doesn't matter:

`simplify/sqrt/fraction`(GAL,kk);
                                       1/2
                                    3 3
                                 -------------
                                     2     3/2
                                 (2 x  + 3)

In my opinion, a big problem with simplify is that the specification of the simplification rules is generically missing. So, deciding what is a bug for it becomes largely a subjective issue.

The interface seems to be involved here. In Maple 13.02 CLI, the output is displayed in the more complex form:

eq:=diff(y(x),x)=x^2*y(x)^4;
                                  d          2     4
                            eq := -- y(x) = x  y(x)
                                  dx
dsolve({eq,y(1)=1});
                                     3 2 1/3        1/2
                            (-(-2 + x ) )    (-1 + 3    I)
                     y(x) = ------------------------------
                                              3
                                     2 (-2 + x )

While in Maple 13.02 GUIs (Classic and Standard) the output is displayed in the more compact form, using the default interface settings. However, if an interface setting change is produced in these GUIs, like executing:

interface(prettyprint=1):

The more complex form is displayed instead.

May be that a "uniformization" was produced afterwards.

I can reproduce this bug:

 
y:=x->exp(-6*x)*k[1]*sin(4*x)+k[2]*cos(4*x):
match(0=diff(y(x),x,x)+B*diff(y(x),x)+C*y(x),x,'s');
                                      true
s; 
          -48 exp(-6 x) k[1] - 16 k[2] + C k[2]
{B = -1/4 -------------------------------------,
                     exp(-6 x) k[1]
                       2     2         2
        8 (13 exp(-6 x)  k[1]  + 4 k[2]  + 18 exp(-6 x) k[1] k[2])
    C = ----------------------------------------------------------,
                 2              2     2
           2 k[2]  + 2 exp(-6 x)  k[1]  + 3 exp(-6 x) k[1] k[2]
                     k[2] (-48 tan(4 x) - 2 C + 32 + 3 C tan(4 x))
    x = -1/6 ln(-1/2 ---------------------------------------------), k[2] = 0}
                                k[1] tan(4 x) (-52 + C)

Actually, match is based on routines of the solve family, and it is well known to have diverse bugs and weaknesses. For this purpose, I would try PDETools:-Solve, that uses different algorithms:

PDETools:-Solve(0=diff(y(x),x,x)+B*diff(y(x),x)+C*y(x),[k[1],k[2]],independentof=x);
                              {k[1] = 0, k[2] = 0}

More than an issue of convert(...,cos) working silly, the problem is both of subdocumentation: the implemented transformation is not stated, and of design: how to specify a particular transformation. E.g. diverse transformation from sin to cos are possible here, like:

trigsubs(sin(4*x)^2):
%[2..3],%[6];
                        2                                 2         2
           [1 - cos(4 x) , 1/2 - 1/2 cos(8 x)], 4 sin(2 x)  cos(2 x)

So, it may be more convenient to specify the transformation rule explicitly:

sinsq:=A::algebraic*sin(a::algebraic)^2=A-A*cos(a)^2:
(expand@applyrule)(sinsq,expand(sin(4*x)^2));
                         6            8            4            2
               128 cos(x)  - 64 cos(x)  - 80 cos(x)  + 16 cos(x)

I agree. Maple has had its development geared much more towards Computer Algebra rather than Symbolic Computation, so that tools for easing many algebraic manipulations are missing. In this case, a procedure for dividing term by term the numerator and denominator by a common factor,

Here it goes a simple minded one, that divides by the numerator, if no factor is provided:

dividend:=proc(ex,f:=numer(ex))
local n,d;
n:=expand(numer(ex)/f):
d:=expand(denom(ex)/f);
n/d;
end proc:

dividend(R*D^2 / ( R*D^2 + s*L + s^2*R*L*C ));
                                       1
                               -----------------
                                           2
                                   s L    s  L C
                               1 + ---- + ------
                                      2      2
                                   R D      D
 
dividend((R*D^2 +R^2*D)/ ( R*D^2 + s*L + s^2*R*L*C ),R*D);
                                     D + R
                                ----------------
                                           2
                                    s L   s  L C
                                D + --- + ------
                                    R D     D

You may try using a pair of rules, one for distributing the sum and the other one for pulling out numbers. Then, assuming that what you want is an indefinite sumation, for such symbolic manipulations it is better to use the inert form Sum, like here:

distribute_sum:=Sum(a::nonunit(algebraic)+b::nonunit(algebraic),r::name)=
Sum(a,r)+Sum(b,r):
factor_sum:=conditional(Sum(A::nonunit(algebraic)*B::nonunit(algebraic),r::name)=
A*Sum(B,r),_type(A,freeof(r))):

S:=Sum(Y(t)*cos(omega*t) + a*sin(omega*t)+b*cos(omega*t),t):

applyrule(distribute_sum,S):
evalindets(%,specfunc(anything,Sum),x->applyrule(factor_sum,x));

  /-----                  \     /-----             \
  | \                     |     | \                |
  |  )   Y(t) cos(omega t)| + a |  )   sin(omega t)|
  | /                     |     | /                |
  |-----                  |     |-----             |
  \  t                    /     \  t               /

             /-----             \
             | \                |
         + b |  )   cos(omega t)|
             | /                |
             |-----             |
             \  t               /