The method of dividing both numerator and denominator by the numerator, plus sorting of the denominator, can be done rather handy with the command dividend:

s:=sum(x^k,k=0..infinity);
                                           1
                                  s := - -----
                                         x - 1

dividend(s);
                                       1
                                     ------
                                     -x + 1

dividend(s,numer(s),[u->u,u->sort(u,[x],ascending)]);
                                       1
                                     -----
                                     1 - x

What I find more interesting about this piece of comparative advertising by Wolfram Research is its existence. As far as I know, for many years until recently (probably about the time Mathematica 8 was launched) Wolfram's official position was simply ignoring that Maple (or any other competitor) exists, stressing the "singularity" of Mathematica. And for me, the key expression in this whole document is "cheap option".

So, on the one hand Wolfram is recognizing that Maple is an option, and on the other hand a concern is being expressed with this option being cheaper. It can only make sense, my conjecture goes, if Wolfram is loosing some of its key clients. I wonder whether the cause is bad economy.

Both documents (by Wolfram Research and by Maplesoft) are quite long and deserve a detailed analysis. But one issue from Maplesoft rebuttal allows a quick comment. It is about the complaints that the Maple timings are being increased largely by the usage of the inefficient command map in the benchmarks, instead of elementwise operators or LinearAlgebra:-Map.  It may well be that the choice of map was done with bad intention. But I wonder how would a tester with good intention (or any other ordinary user) come to know those big differences in efficiency between these map-like commands? By reading ?map , ?LinearAlgebra,Map and ?operators,elementwise I do not find any clear information on those differences (notwithstanding that I am aware of them). May be that something more could be get by searching this site, but in all this episode shows a deficit in the documentation of Maple. As I see it, a consequence of poor documentation is a deteriorated perceived value of the product. 

This is another elementary example of the automatic simplification becoming an obstacle for symbolic computations under hand control. Interestingly, in Maxima, automatic simplification works the other way, by combining the factors as the OP wishes:

(%i2) 5^(1/2)*5^2
(%o2) 5^(5/2)

Moreover, in Maxima, automatic simplification can be disabled, in which case the terms are not combined:

(%i3) simp:false
(%i4) 5^(1/2)*5^2
(%o4) 5^(1/2)*5^2

I find that a better systen should have the option for disabling automatic simplification with suitable safeguards.

This is another elementary example of the automatic simplification becoming an obstacle for symbolic computations under hand control. Interestingly, in Maxima, automatic simplification works the other way, by combining the factors as the OP wishes:

(%i2) 5^(1/2)*5^2
(%o2) 5^(5/2)

Moreover, in Maxima, automatic simplification can be disabled, in which case the terms are not combined:

(%i3) simp:false
(%i4) 5^(1/2)*5^2
(%o4) 5^(1/2)*5^2

I find that a better systen should have the option for disabling automatic simplification with suitable safeguards.

@acer 

Another example of something that looks wrong lately with Classic is the error messages sent to the Linux console when launched, of the form:

*** glibc detected *** /opt/maple16/bin.IBM_INTEL_LINUX/maplew: free(): 
invalid pointer: 0x0926ad70 ***

They occur since Maple 13. They look like a problem with the (Java) memory manager, but it has to be debugged to say something for certain.

Whatever its cause, in recent times, my experience with the Classic GUI on (diverse distros of) Linux is of frequent crashes under copy&paste or cursor operations.

@acer 

Another example of something that looks wrong lately with Classic is the error messages sent to the Linux console when launched, of the form:

*** glibc detected *** /opt/maple16/bin.IBM_INTEL_LINUX/maplew: free(): 
invalid pointer: 0x0926ad70 ***

They occur since Maple 13. They look like a problem with the (Java) memory manager, but it has to be debugged to say something for certain.

Whatever its cause, in recent times, my experience with the Classic GUI on (diverse distros of) Linux is of frequent crashes under copy&paste or cursor operations.

Yes, but the problem is the default setting for the Standard GUI in document mode and 2-D input, combined with the introductory documentation that emphazises this usage mode. This is very paternalistic, and tends to generate a toy-like impression about the capabilities of the system.

And indeed, the bloated design of the Standard GUI is very far from KISS.

Yes, but the problem is the default setting for the Standard GUI in document mode and 2-D input, combined with the introductory documentation that emphazises this usage mode. This is very paternalistic, and tends to generate a toy-like impression about the capabilities of the system.

And indeed, the bloated design of the Standard GUI is very far from KISS.

I am pessimistic about such hacks. There are several changes that the older version of the Classic GUI may not handle. For instance, this DAG exists in Maple 16:

kernelopts(dagtag=POLY);
                                       17

That is missing in Maple 13, yielding:

Error, unknown data structure label POLY

So, if the Maple 13 Classic GUI receives it from the Maple 16 kernel it will have problems. Also, the format of rtables stored in Classic worksheets seems to have changed from Maple 15 to 16 (it may cause a crash when a worksheet saved in 15 is opened in 16). And you have the ssystem issue which is specific of Maple 16 Classic.

I am pessimistic about such hacks. There are several changes that the older version of the Classic GUI may not handle. For instance, this DAG exists in Maple 16:

kernelopts(dagtag=POLY);
                                       17

That is missing in Maple 13, yielding:

Error, unknown data structure label POLY

So, if the Maple 13 Classic GUI receives it from the Maple 16 kernel it will have problems. Also, the format of rtables stored in Classic worksheets seems to have changed from Maple 15 to 16 (it may cause a crash when a worksheet saved in 15 is opened in 16). And you have the ssystem issue which is specific of Maple 16 Classic.

@acer 

Yes. I find that a command "AddOptions" is frequently needed. The counterpart of IntegrationTools:-StripOptions.

@acer 

Yes. I find that a command "AddOptions" is frequently needed. The counterpart of IntegrationTools:-StripOptions.

There are several commands for substitutions of subexpressions like two-argument eval, subs, algsubs, and even use. They provide different  "pattern-matching" facilities: eval operates on the DAG representation of the expression with some mathematical awareness,  subs operates syntactically on a tree representation, algsubs is more mathematical, but sadly long ago "frozen", and use operates at the automatic simplification time.

The discussions of closed source, comercial vs open-source, free CAS, bug fixing in each case and their learning curves are quite interesting but rather off topic to pattern matching. I would suggest branching them.

Carl, a nice surprise reading your posts here! I hope to read you again also elsewhere.