@tomleslie 

There are several issues to discuss in what you say, I address only a few. When you say "the answer is always true" you are talking true in mathematical sense. A computation of a "true" value is something different. In your worksheet you are testing equality in a boolean context, equivalent to using evalb, which tests memory address equality. This is a particularly weak representation for mathematical equality as it may miss many cases, precisely what you are showing. Maple has several tools testing equality at different strengths. In particular verify provides both ready to use and programable equality verifications much stronger than evalb.

@Preben Alsholm 

Jacques has told here several stories of individuals introducing a regression in the belief they were making an upgrade.

@tomleslie 

For every command, or combination, there are always clases of expressions for which it will fail. This is basically the zero equivalence problem, generically known to be unsolvable. But, in practice, it can be worked out for some clases of expressions.

@acer 

Note that I have warned about this new behavior elsewhere...

@tomleslie 

Obviously, you need expand, rather than simplify:

> simplify(x*(1+x));
                                   x (1 + x)
> expand(x*(1+x));
                                      2
                                     x  + x

But expand does not map automatically as simplify. See the output of:

trace(expand):
trace(simplify):
simplify(M1+M2);
expand(M1+M2);

The documentation of both commands is somewhat poor.

@shzan 

OK, so split works but you want additionally to flip the integration limits of the resulting integrals where u becomes the lower limit. I am adding this part to my answer.

@shzan 

I wonder what do you mean exactly by would not work.

@itsme 

So you know already his opinions on these issues. I consider that the founder of Maple understands them much better than us...

@Markiyan Hirnyk 

No, this syntax was introduced system-wide in Maple 12, see ?updates,Maple12,symbolics (actually it was introduced in Maple 11 within a restricted scope). But its documentation is poor, mainly a paragraph in ?value. And sadly, its implementation was never finished, meaning that some commands still do not handle properly this syntax after seven years or so.

@itsme 

I suggest you to read the interview to Gaston Gonnet linked above.

@Rouben Rostamian  

Why is a story. Shortly, an alternative solution for your case is using a conditional rule like:

> applyrule(conditional(Int(f::anything, r::equation) = z,
_type(_lhs(r),identical(t))) , Int(f, t = 2 .. 5));
                                       z

@acer 

Yes openness was one of Maple great strengths, but it is far less than it was. As you have described in this thread merely inspecting the code of a package may involve a lot of difficulties for the user nowadays. It is not enough that you post fixes to Library code on this site. It is necessary that many more members of the user community get involved as it was in the far past. But it would need a different approach from Maplesoft, providing access to documented source code, a platform for collaborative development, and perhaps a different business model.

In this interview cited by Jacques, Gaston Gonnet made though the comment: "Maybe now it's even too late to go that route" (now was 2005).

@acer 

Note that your narrative is approaching Wolfram's Why You Do Not Usually Need To Know About Internals.

@itsme 

I have written time ago some tools that make all that cycling over members of modules, showing the overall structure, the code of procedures, content of tables, etc. Idem for old style "slash" hierarchies, like `xxx/yyy/zzz` (note, by the way, that some packages have a mixed module-slash organization). I use them regularly for looking at diverse sectors of the system (e.g. Explore), sadly mostly undocumented. I think that writing the core of those tools took me a few hours at most. 

@Carl Love 

I have not made significant timing comparisons between these two builtin procedures, but clearly, the order of the computations is different. Somehow add calls the expansion of the list, while `+` receives it expanded:

> X:=[1, 3, 8, 9, 10] :
> trace(add):
> trace(`+`):
> add(X);
execute add, args = X
                                       31
> `+`(X[]);
execute +, args = 1, 3, 8, 9, 10
                                       31