@Carl Love 

Just select-copying 2D input and output from the Standard GUI and pasting at the editor here (or at any text editor). A complementary view of the process is obtained by debugging Typesetting:-Parse.

Certainly, this is the case. In 1D:

if(1>0) then 1 else 0 end if;
                               1

While in 2D:

if(1>0) then 1 else 0 end if;
Error, unable to parse
 Typesetting:-mambiguous(Typesetting:-mambiguous(

   ifApplyFunction(1gt0) then, 

   Typesetting:-merror("unable to parse")) 1 else 0 end ifsemi)

The 2D error message shows that if(1>0) is parsed as a function call by the 2D parser. Is it the intended behavior or a bug? I guess that this difference is nowhere documented. Indeed, Carl's advice is good: never use 2D input. It is too buggy and/or too poorly documented..

Certainly, this is the case. In 1D:

if(1>0) then 1 else 0 end if;
                               1

While in 2D:

if(1>0) then 1 else 0 end if;
Error, unable to parse
 Typesetting:-mambiguous(Typesetting:-mambiguous(

   ifApplyFunction(1gt0) then, 

   Typesetting:-merror("unable to parse")) 1 else 0 end ifsemi)

The 2D error message shows that if(1>0) is parsed as a function call by the 2D parser. Is it the intended behavior or a bug? I guess that this difference is nowhere documented. Indeed, Carl's advice is good: never use 2D input. It is too buggy and/or too poorly documented..

@digerdiga 

One way is using a neutral operator, `&*` say, for the generation of the symbolic expression:

L:=(expand((D-2)^2));
                           2          
                          D  - 4 D + 4

map(u->u&*f(x),L);
             2                                     
            D  &* f(x) + (-4 D) &* f(x) + 4 &* f(x)

And then, if you need an actual computation, substitute `&*` with a overloaded procedure that computes as `*` for numeric coefficients and applies D in the derivative terms.

@digerdiga 

One way is using a neutral operator, `&*` say, for the generation of the symbolic expression:

L:=(expand((D-2)^2));
                           2          
                          D  - 4 D + 4

map(u->u&*f(x),L);
             2                                     
            D  &* f(x) + (-4 D) &* f(x) + 4 &* f(x)

And then, if you need an actual computation, substitute `&*` with a overloaded procedure that computes as `*` for numeric coefficients and applies D in the derivative terms.

@Axel Vogt 

Here, this integral is being computed by method meijerg, which indeed seems to produce more compact results when it does not fail or produce wrong results. And it is being computed by method meijerg because the method lookup, which executes before and uses pattern matching, fails. And it fails because the table lookup is used only when the integrand contains sin, cos or exp. 

Yes, tracing Algebraic:-RecursiveDensePolynomials:-maple2rpoly shows that it keeps calling itself:

kernelopts(opaquemodules=false):
a,b,c:= 'RootOf(x^3-x^2-x-1, x, index= k)' $ k= 1..3:
trace(Algebraic:-RecursiveDensePolynomials:-maple2rpoly):
evala(
     ((a^2014-b^2014)/(a-b)) +
     ((b^2014-c^2014)/(b-c)) +
     ((c^2014-a^2014)/(c-a))
);

Yes, tracing Algebraic:-RecursiveDensePolynomials:-maple2rpoly shows that it keeps calling itself:

kernelopts(opaquemodules=false):
a,b,c:= 'RootOf(x^3-x^2-x-1, x, index= k)' $ k= 1..3:
trace(Algebraic:-RecursiveDensePolynomials:-maple2rpoly):
evala(
     ((a^2014-b^2014)/(a-b)) +
     ((b^2014-c^2014)/(b-c)) +
     ((c^2014-a^2014)/(c-a))
);

A quick plot check of the output for the first example against your result suggests that Maple succeeds in producing an equivalent result, though indeed in more obscure and less useful form. Maple uses a pattern matching technique. See the (rather long) output from:

g := (p, q) -> 1/(x+p)/(x+(p*q-1)/q);
with(inttrans):
infolevel[patmatch]:=3:
mellin(g(3, 2), x, s);

This means, that it looks for a class of functions (more general than g(p,q)) for which g(3,2) fits, and then specializes the general transform expression for this class to the set of parameters that makes the fit. Clearly, this approach cannot take profit, in general, of any simplification that is available when starting from a more restricted form of function as in your approach.

The next question is whether your approach, using contour integration, could be implementable algorithmically. For instance, you say at a point: "Use a circular contour to get". What I wonder (and I have wondered for years), could an automated system decide correctly which contour would be better to take? Or, is it algorithmic to decide whether to take a circular contour or whatever? As we have discussed several times here, the contour integration method implemented in Maple is quite primitive, and, as far as I have seen, there is nothing like a mechanism for computing contours and less deciding which one to choose. And I have no much clue what is the status in other CAS, but my guess is that it is not much better. Moreover, I wonder how much research has been made on this subject (symbolic contour integration) in recent years. My feeling is that there has been too little.

@Carl Love 

Well, it is a system of two equations and three variables, so, a priori, one of the variables is a parameter. See, e.g. the output from:

> solve({x^2+y^2+z^2 = 3, x+y+z = 0}, {x,y,z},parametric,real);

Indeed, it uses SolveTools:-SemiAlgebraic. This functionality, seems to have been finished very late in the development of Maple 17, what may explain its poor documentation and somewhat rough interface, as you have noted. Anyway, it looks like an important step forward, filling a big hole.

@Carl Love 

Well, it is a system of two equations and three variables, so, a priori, one of the variables is a parameter. See, e.g. the output from:

> solve({x^2+y^2+z^2 = 3, x+y+z = 0}, {x,y,z},parametric,real);

Indeed, it uses SolveTools:-SemiAlgebraic. This functionality, seems to have been finished very late in the development of Maple 17, what may explain its poor documentation and somewhat rough interface, as you have noted. Anyway, it looks like an important step forward, filling a big hole.

@Carl Love 

Yes, it looks as a bug (another one):

> p:=lhs(r):
> ex:=(a-d)*(c^2+a^2-b^2):
> patmatch(ex,p,'s');s;s:='s':
                                      true
                            2        2    2
                      [X = a , Y = -b  + c , k = 1, n = 1]

> ex:=(e+d)*(c^2+a^2-b^2):
> patmatch(ex,p,'s');s;s:='s':
                                      true
                          [X = e, Y = d, k = 1, n = 1]

A restriction to names screens out such cases:

> p:=(X::nonunit(name)^k::integer + Y::nonunit(name)^k::integer)^n::integer*
> (X::nonunit(name)^k::integer - Y::nonunit(name)^k::integer)^n::integer:
> ex:=(a^2-c^2)^3*(a^2+c^2)^3;
                                  2    2 3   2    2 3
                          ex := (a  - c )  (a  + c )
> patmatch(ex,p,'s');s;s:='s':
                                      true
                          [X = a, Y = c, k = 2, n = 3]
> ex:=(a-c)^3*(a+c)^3;
                                         3        3
                            ex := (a - c)  (a + c)
> patmatch(ex,p,'s');s;s:='s':
                                      true
                          [X = a, Y = c, k = 1, n = 3]
> ex:=(a-d)*(c^2+a^2-b^2):
> patmatch(ex,p,'s');s;s:='s':
                                     false
                                       s
> ex:=(e+d)*(c^2+a^2-b^2):
> patmatch(ex,p,'s');s;s:='s':
                                     false
                                       s

Hence, a workaround rule is:

> r3:=(X::nonunit(name)^k::integer + Y::nonunit(name)^k::integer)^n::integer*
> (X::nonunit(name)^k::integer - Y::nonunit(name)^k::integer)^n::integer
> =(X^(2*k)-Y^(2*k))^n:
> applyrule(r3,ee);		      
                             4    4 3   2    2    2
                           (a  - c )  (a  - b  + c )
> applyrule(r3,e2);		      
                             2    2 3   2    2    2
                           (a  - c )  (a  - b  + c )
> applyrule(r3, (a-d)*ee);
                         4    4 3           2    2    2
                       (a  - c )  (a - d) (a  - b  + c )

Indeed, identifying bugs in the PatternMatching package seems to me very important, so that I would suggest showing any weird result.

@Carl Love 

Yes, it looks as a bug (another one):

> p:=lhs(r):
> ex:=(a-d)*(c^2+a^2-b^2):
> patmatch(ex,p,'s');s;s:='s':
                                      true
                            2        2    2
                      [X = a , Y = -b  + c , k = 1, n = 1]

> ex:=(e+d)*(c^2+a^2-b^2):
> patmatch(ex,p,'s');s;s:='s':
                                      true
                          [X = e, Y = d, k = 1, n = 1]

A restriction to names screens out such cases:

> p:=(X::nonunit(name)^k::integer + Y::nonunit(name)^k::integer)^n::integer*
> (X::nonunit(name)^k::integer - Y::nonunit(name)^k::integer)^n::integer:
> ex:=(a^2-c^2)^3*(a^2+c^2)^3;
                                  2    2 3   2    2 3
                          ex := (a  - c )  (a  + c )
> patmatch(ex,p,'s');s;s:='s':
                                      true
                          [X = a, Y = c, k = 2, n = 3]
> ex:=(a-c)^3*(a+c)^3;
                                         3        3
                            ex := (a - c)  (a + c)
> patmatch(ex,p,'s');s;s:='s':
                                      true
                          [X = a, Y = c, k = 1, n = 3]
> ex:=(a-d)*(c^2+a^2-b^2):
> patmatch(ex,p,'s');s;s:='s':
                                     false
                                       s
> ex:=(e+d)*(c^2+a^2-b^2):
> patmatch(ex,p,'s');s;s:='s':
                                     false
                                       s

Hence, a workaround rule is:

> r3:=(X::nonunit(name)^k::integer + Y::nonunit(name)^k::integer)^n::integer*
> (X::nonunit(name)^k::integer - Y::nonunit(name)^k::integer)^n::integer
> =(X^(2*k)-Y^(2*k))^n:
> applyrule(r3,ee);		      
                             4    4 3   2    2    2
                           (a  - c )  (a  - b  + c )
> applyrule(r3,e2);		      
                             2    2 3   2    2    2
                           (a  - c )  (a  - b  + c )
> applyrule(r3, (a-d)*ee);
                         4    4 3           2    2    2
                       (a  - c )  (a - d) (a  - b  + c )

Indeed, identifying bugs in the PatternMatching package seems to me very important, so that I would suggest showing any weird result.

if the 2D parser is so buggy, a handwriting parser looks to me like a nightmare...

if the 2D parser is so buggy, a handwriting parser looks to me like a nightmare...