@Carl Love 

He says, I think:

> myterm:=(f(3,4)+f(2,2))*f(1,1);
myterm := ((x[1] + x[2] + x[3]) (y[1] + y[2] + y[3] + y[4])
     + (x[1] + x[2]) (y[1] + y[2])) x[1] y[1]

> myterm:=expand(myterm);
                2     2         2                 2                 2
myterm := 2 x[1]  y[1]  + 2 x[1]  y[1] y[2] + x[1]  y[1] y[3] + x[1]  y[1] y[4]
...

So, the issue is to get back (f(3,4)+f(2,2))*f(1,1) from the expanded expression. A step towards this end seems to be made by:

> simplify(myterm,size);
2 ((y[1] + y[2] + 1/2 y[3] + 1/2 y[4]) x[1]
     + (y[1] + y[2] + 1/2 y[3] + 1/2 y[4]) x[2]
     + 1/2 x[3] (y[1] + y[2] + y[3] + y[4])) y[1] x[1]

@Carl Love 

That is different to the original statement.

I do not agree with some of your points. The main problem with current Maple develpment trends is about priorities. Too many new features are just fancy toys, as you say, mostly to play around. But the counterpart is that too many fundamental, long standing problems are left aside or are barely touched. Also, I do not like your generalization. I never get mesmorized by all those new bells and whistles. And the fraction of fixed bugs is probably quite low. For sure, there are many user-known bugs around for 10-20 years. And who knows the total amount of bugs? Certainly, new features bring new bugs and also, quite a number of regression bugs are introduced with every release.

About (printed) books, it is probably a lost case. If packages are updated weekly, say (and I am in favor of Edgardo's initiative), the only documentation feasible is electronic and collaborative.

@Carl Love 

This is a funny formatting problem, blocking the edit menu...

I think that you could edit it by using the direct link to the editor:

http://www.mapleprimes.com/EditAnswer/204912

I have noticed this chronological quirk some ten days ago. You are right, this list "was".

@Markiyan Hirnyk 

It doesn't work in this partial case, r=1 say, for the same reason explained above when an assumption like r>0 holds, namely some expressions in the condition procedures evaluate to false. Look again at `int/gmeijer/cond`[14]:

> trace(`int/gmeijer/cond`[14]):
> int(BesselJ(2, k)*BesselJ(1, 1500*k), k = 0 .. infinity, method = meijergspecial);
{--> enter `int/gmeijer/cond`[14], args = 0, 0, 0, 0, 0, 0, 0, 0, 2, 1/2
memory used=1.1MB, alloc=30.3MB, time=0.08
                                     false
<-- exit `int/gmeijer/cond`[14] (now in int/gmeijer/cond2) = false}
{--> enter `int/gmeijer/cond`[14], args = 0, 0, 0, 0, 0, 0, 0, 2, 0, -1/2
                                     false
<-- exit `int/gmeijer/cond`[14] (now in int/gmeijer/cond2) = false}
int(BesselJ(2, k) BesselJ(1, 1500 k), k = 0 .. infinity,
    method = meijergspecial)

@Carl Love 

This integral is computed by the method meijergspecial. The execution of the procedure `int/gmeijer/cond2`, involves a lot of boolean conditions. See the output of:

> trace(`int/gmeijer/cond2`):
> int(BesselJ(2, r*k)*BesselJ(1, 1500*k), k= 0..infinity,method=meijergspecial);
> int(BesselJ(2, r*k)*BesselJ(1, 1500*k), k= 0..infinity,method=meijergspecial) 
assuming r>0;

Now, the result this procedure is true without the assumption and false with it. It happens because some conditions yield FAIL in the first case and false in the second one:

> trace(`int/gmeijer/cond`[14]):
> int(BesselJ(2, r*k)*BesselJ(1, 1500*k), k= 0..infinity,method=meijergspecial);
{--> enter `int/gmeijer/cond`[14], args = 0, 0, 0, 2*argument(r), 0, 0, 0, 0, 2
, 1/2
                                      FAIL
<-- exit `int/gmeijer/cond`[14] (now in int/gmeijer/cond2) = FAIL}
                                       0
> int(BesselJ(2, r*k)*BesselJ(1, 1500*k), k= 0..infinity,method=meijergspecial) assuming r>0;
{--> enter `int/gmeijer/cond`[14], args = 0, 0, 0, 0, 0, 0, 0, 0, 2, 1/2
                                     false
<-- exit `int/gmeijer/cond`[14] (now in int/gmeijer/cond2) = false}
{--> enter `int/gmeijer/cond`[14], args = 0, 0, 0, 0, 0, 0, 0, 2, 0, -1/2
                                     false
<-- exit `int/gmeijer/cond`[14] (now in int/gmeijer/cond2) = false}
...

These conditions compute expressions like:

> showstat(`int/gmeijer/cond`[14],3):
`int/gmeijer/cond`[14] := proc(phi, bstar, cstar, argsigma, argomega, mu, rho, u, v, alpha)
       ...
   3     testeq(signum(Pi-abs(argomega-argsigma-(cstar+bstar)*Pi)-1))
       ...

whose value depend on assumptions. So, as it stands, the logic of this code looks upside down. Perhaps it was never adapted to work with assumptions.

@Markiyan Hirnyk 

I am begining to think that part of this issue (not all) is related to the behavior of automatic simplification for this exponent of type `*` like 2*k, instead of a name like k. Compare:

> 0^k;
                                       0
> '0^k';
                                       0
> 0^(2*k);
                                      (2 k)
                                     0
> restart:
> for x from 0 to 0 do print(evalf(sum(0^k, k = 0 .. 10))) end do;
                                       0.
> for x from 0 to 0 do print(evalf(sum(x^k, k = 0 .. 10))) end do;
                                       0.

> restart:
> for x from 0 to 0 do print(evalf(sum(0^(2*k), k = 0 .. 10))) end do;
                                       1.
> for x from 0 to 0 do print(evalf(sum(x^(2*k), k = 0 .. 10))) end do;
                                       1.

@mehdi jafari 

I have sent several emails to Bryon in recent months about the new problems in this site since the last changes. Most of them were not answered. And when answered, no subsequent action was taken. So, I am allowed to think the worst.

@acer 

Sometimes, for some release, build ids for the interface, kernel, library and installer differ. And even ids for Classic and Standard interfaces may be different.

@Michael 

This site is falling appart. If you did not yet, see a partial list of new problems as listed in this thread.

All evidence suggest to me that the answer is no (i.e. nothing beyond betatesting or the like). But, I wonder what software companies do it. Wolfram Research?

@ThU 

Rather, typesetting, i.e. TypeMK markup details are not documented at all! This is a very unfortunate consequence of widespread developer's belief/argumentation that code considered subject to further change does not have to be documented (for the users). But TypeMK has been around already like ten years... So, besides experimentation, frequently the best source of information on this subject are posts here.

@nm 

It looks like the generality of Maple experts is not fond of wiki sites...

Surprises occur in this site all the time. It appears that all my posts (with account jakubi) that are shown (many are not) earlier than April 27 2010 have been redated, see here. And subsquent comments have also been assigned fake dates. In one case, almost five years later (I have the original version archived). If comment dates are false, how could they ever be ordered chronologically?

On a second thought, is this just another bug or historical revisionism?