@leaky 

I think that it would be more constructive to write a good procedure for un-rationalizing (rather than go with long strings of nested commands and inverses). Something along this sketch:

unrat:=proc(ex::`&under`(radical,numer))
local n:=numer(ex),d:=denom(ex):
op(0,n)(normal(op(1,n)/d),op(2,n))/d^(1-op(2,n));
end proc:

f:=sqrt(2*x+2)/(x+1):
unrat(f);

                                       1/2
                                      2
                                   ----------
                                          1/2
                                   (x + 1)

Care has to be taken on the validity of the operations.

@Bryon 

"Edit" is probably the feature that I use most. So, it is really very inconvenient for me that it has been removed from the top level menu. On the other hand, seldom or never I use other items now at the top level. In any case, it should be up to the user to decide which features have to be on top.

@Carl Love 

I do not agree with your comment. In regards to scientists in general, there is about everything. Some persons are delighted to talk about their activities and plans, while some other don't. And in fact, currently, there is an increasing trend towards collaborative work through specialized social networks, implying more openness.

And about the specific situation of CAS, a good case for comparison is Mathematica. If you read Wolfram's blog, you will find that quite often he writes about his plans for future versions of Mathematica. Of course, it is marketing (no doubt he is very smart at that), but nevertheless it is useful information for Mathematica users.

And even here, occasionally, Maple developers have described plans and work in progress. So, I do not find that my question is unfair or unpolite at all. In any case, an answer without providing any detail can always be given. But my opinion is that an "open" development process, with systematic user feedback, is always better.

@Kitonum 

Basically, algsubs is limited to rational expressions (patterns). Beyond them, something more can be done by combining with frontend, but in my opinion general pattern matching techniques are more clear, hence they represent frequently a better option (unless you hit a bug). Consider, for instance, a variation of the example above with symbolic exponents:

eq:=sum(x[i]^(i*n),i=1..5)=Sum(x[i]^(i*n),i=1..5):
applyrule(eq,(x[1]^n+x[2]^(2*n)+x[3]^(3*n)+x[4]^(4*n)+x[5]^(5*n)+a)/cos(phi));
                             /  5            \
                             |-----          |
                             | \        (i n)|
                             |  )   x[i]     | + a
                             | /             |
                             |-----          |
                             \i = 1          /
                             ---------------------
                                   cos(phi)

algsubs(eq,(x[1]^n+x[2]^(2*n)+x[3]^(3*n)+x[4]^(4*n)+x[5]^(5*n)+a)/cos(phi));
Error, (in algsubs) no variables appearing rationally in pattern

@Kitonum 

Basically, algsubs is limited to rational expressions (patterns). Beyond them, something more can be done by combining with frontend, but in my opinion general pattern matching techniques are more clear, hence they represent frequently a better option (unless you hit a bug). Consider, for instance, a variation of the example above with symbolic exponents:

eq:=sum(x[i]^(i*n),i=1..5)=Sum(x[i]^(i*n),i=1..5):
applyrule(eq,(x[1]^n+x[2]^(2*n)+x[3]^(3*n)+x[4]^(4*n)+x[5]^(5*n)+a)/cos(phi));
                             /  5            \
                             |-----          |
                             | \        (i n)|
                             |  )   x[i]     | + a
                             | /             |
                             |-----          |
                             \i = 1          /
                             ---------------------
                                   cos(phi)

algsubs(eq,(x[1]^n+x[2]^(2*n)+x[3]^(3*n)+x[4]^(4*n)+x[5]^(5*n)+a)/cos(phi));
Error, (in algsubs) no variables appearing rationally in pattern

@ecterrab 

This is an interesting feature, implementing the concept of a pair of expressions, sadly undocumented though. Yet it seems to operate purely at a typographical level. Namely:

v2:=Typesetting:-mcomplete(Typesetting:-Typeset(v[satellite]^2), 
Typesetting:-Typeset(v__satellite^2));

does not seem to be recognized by the kernel as the square of anything. For instance, neither of these statements:

sqrt(v2) assuming v[satellite]>0;
sqrt(v2) assuming v__satellite>0;

makes a simplification the way it is expected for a square:

sqrt(x^2) assuming x>0;
                               x

Is there any other hidden trick?

On the other hand, I do not understand your last comment. Is that replacement of the print/foo mechanism by a "PrintTools" package an expresion of desire or work in progress?

@Allan Wittkopf 

What exactly is a 'graze' condition?

In my opinion, a statement like "my command is more powerful than yours" is misleading. First, it is not the subject of the OP question (and for me the context of this question is not clear). Second, how do you measure the "power" of a command? Certainly a single statement is not a test. These two and other commands have strong and weak points. And they may be used in many different ways by means of options and diverse constructs, with diverse results. And they have bugs (frequently many bugs). And in particular, neither applyrule (i.e. the PatternMatching package) nor algsubs have been maintained nor improved significantly for many years. So, I would suggest avoiding the usage of this kind of wording.

In my opinion, a statement like "my command is more powerful than yours" is misleading. First, it is not the subject of the OP question (and for me the context of this question is not clear). Second, how do you measure the "power" of a command? Certainly a single statement is not a test. These two and other commands have strong and weak points. And they may be used in many different ways by means of options and diverse constructs, with diverse results. And they have bugs (frequently many bugs). And in particular, neither applyrule (i.e. the PatternMatching package) nor algsubs have been maintained nor improved significantly for many years. So, I would suggest avoiding the usage of this kind of wording.

What error message? I get the "expected" result:

gradf(u,v);
                                    _       2 _
                                2 u e  + 3 v  e
                                     u         v

What error message? I get the "expected" result:

gradf(u,v);
                                    _       2 _
                                2 u e  + 3 v  e
                                     u         v

@Christopher2222 

As said many times here and elsewhere, automatic simplification cannot be avoided, and moreover it is critical, in the way it works, for all the Maple system to work properly. It is at the core of its design. Other CAS are designed differently and consequently produce different output forms. Certainly, in many situations of symbolic computation it would be very convenient that the automatic simplification could be disabled. But that would be another system, not Maple...

@Christopher2222 

As said many times here and elsewhere, automatic simplification cannot be avoided, and moreover it is critical, in the way it works, for all the Maple system to work properly. It is at the core of its design. Other CAS are designed differently and consequently produce different output forms. Certainly, in many situations of symbolic computation it would be very convenient that the automatic simplification could be disabled. But that would be another system, not Maple...

Certainly, all the mathematical typesetting rules say that the exponent is placed in the wrong place. But, the issue here is the combination of computation with typesetting. In your example, the subindex "satellite" is typesetting, and the exponent "2" is computation (the second operand of the power constructor `^`):

v__satellite^2:
op(0..,%);
                       ^, v__satellite, 2

So, your concern on how it looks on the screen cannot avoid this mixed character. 

No the way that I have outlined above, as a pair of expressions, was never implemented. It was always a single expression. Just that it has changed in Maple 17 which one. Actually, I am following here the scheme that Jacques has described here. Precisely, my understanding is that a single expression can never provide a satisfactory solution, neither for typesetting nor for computation. And it is inefficient and fragile.

Erik, I think that the implementation of your request would require moving from a single expression, that is both computational and typesetting, to a pair of expressions (computational , typesetting). The first one for interaction with the kernel and the second one for interaction with the GUI. In your example it would be something like (v__satellite^2 , `#msubsup(mi(v),mi(satellite),mn(2))`).