@Mac Dude 

Maple, as a system, includes a Java sector which does execute when a Standard GUI worksheet opens. Additionally, depending on the content of this worksheet, the historical C sector of Maple may also execute along this process. Now, the main problem of the Java virtual machine (JVM) when opening worksheets is about complexity over storage size. Meaning that the OP's 17MB worksheet might require more heap space than your 100MB one. So yes, it appears that the best workaround available in these situations of complexity is trying to increase the maximum heap size above the default (512MB say) as much as possible. 

About looking what happens in these situations, actually a JVM monitoring tool is needed. I use mainly VisualVM for this purpose.

@MathyMaple 

Maple automatically simplifies some expressions and any evaluation comes in at a later stage. This evaluation step can be suppressed by enclosing the expression in single (forward) quotes, see it in this example:

> '0^k';
                                       0

Sadly, automatic simplification cannot be avoided as here, and what can be done as workaround is using alternative expressions not affected by it.

@acer 

For years I been have expressing my opinion, here and elsewhere, that checksums should be provided for installer files so that download errors could be identified before installation. Yet, the number of similar cases for Maple 18x makes me wonder about the possibility of an  installer already corrupted at the Maplesoft side.

@acer 

Instead of nested convert commands, it uses to be a simpler syntax a single convert command with option compose, like:

> simplify(convert(ee,compose,hypergeom,StandardFunctions));
                         -2 LaguerreL(n, l + 1/2, y) n

@Carl Love 

Actually, an entry for the case of a single coefficient is missing in your statement. As it stands we get:

> L(a*f(x),g(x));
                                L(a f(x), g(x))

@JohnS 

Another approach is using conditional rules like in this (over)conservative implementation:

> define(L,orderless,multilinear,
> conditional(L(a::name*b::function,c::function) = a*L(b,c),_evalb(a<>x)),
> conditional(L(a::name*b::function,c::name*d::function) = a*c*L(b,d),_evalb(a<>x) and _evalb(c<>x))
> );
> val:=L(c*y1(x)+d*y2(x), e*z1(x)+f*z2(x)) ;
val := c e L(y1(x), z1(x)) + c f L(y1(x), z2(x)) + d e L(y2(x), z1(x))
     + d f L(y2(x), z2(x))
> diff(val,c);
                     e L(y1(x), z1(x)) + f L(y1(x), z2(x))
>  L(x*f(x),g(x)) ;
                                L(x f(x), g(x))
>  L(x*f(y),g(y)) ;
                                L(x f(y), g(y))
>  L(x*f(y),g(x)) ;
                                L(x f(y), g(x))
>  L(f(y),x*g(x)) ;
                                L(x g(x), f(y))

@JohnS 

An approach is using transformation rules specific for the name x first, such that e.g. L(x*f(x),g(x)) remains as is. Something like that can be done:

> define(L,orderless,multilinear,
> L(x*b::anyfunc(identical(x)),c::function) = %L(x*b,c),
> L(x*b::anyfunc(identical(x)),x*d::anyfunc(identical(x))) = %L(x*b,x*d),
> L(a::name*b::function,c::function) = a*L(b,c),
> L(a::name*b::function,c::name*d::function) = a*c*L(b,d)
> );
> 
> val:=L(c*y1(x)+d*y2(x), e*z1(x)+f*z2(x));
val := c e L(y1(x), z1(x)) + c f L(y1(x), z2(x)) + d e L(y2(x), z1(x))
     + d f L(y2(x), z2(x))
> diff(val,c);
                     e L(y1(x), z1(x)) + f L(y1(x), z2(x))
>  L(x*f(x),g(x)) ;
                                %L(x f(x), g(x))
>  L(x*f(y),g(y)) ;
                                x L(f(y), g(y))
>  L(x*f(y),g(x)) ;
                                x L(g(x), f(y))
>  L(f(y),x*g(x)) ;
                                %L(x g(x), f(y))

Note, however, that the design of define is to keep transforming, something that never ends for L(x*f(x),g(x)). This is actually a design bug in my opinion, as we want here transform only once. A workaround is transforming to the inert form %L(x*f(x),g(x)).

@Carl Love 

If such a procedure were available in the library, e.g. as a part of a missing "SumTools" package, would you look at its code and say that it is not elegant, or just say use it? In fact, many procedures in the library are much less elegant than yours and seldom somebody cares about that. So, in my opinion, the main issue is that many tools for symbolic computation like this one are missing in the system.

@acer 

Yes, the list Typesetting:-UnicodeToEntity contains the entry 9642 = "blacksquare", with 9642 = hex 25AA. Synonyms in Typesetting:-OperatorDupMap are: "▪" = "▪", "▪" = "▪", "▪" = "▪"

@Kitonum 

You might try in the Standard GUI something like:

cat(`&#`,convert("25AA",decimal,hex),`;`);

On my system (Linux 32-bit) Standard output typesets as an unavailable character instead of a solid square, may be a problem of fonts on this platform. Indeed, copy&paste of this output on a text application, the CLI in particular, typesets as a solid block. So, I guess that it might work in Standard on other platforms.

@Carl Love 

In my opinion, this is a case where missing specifications makes it subjective to decide what is wrong. In any case, it seems to deserve a SCR, and hopefully a developer will decide after how he feels it at that moment.

Yes, the process of updating frontend routines for accepting as options relevant environment variables, in a more functional style, has been going on very slowly. E.g. for solve it was in Maple 13, see ?updates,Maple13,symbolic > Solve Enhancements.

@Carl Love 

About looking into data structures, dismantle is, generically, more close to actual DAGs than ToInert. In this case:

> dismantle(P);
SUM(3)
   PROD(5)
      NAME(4): a
      INTPOS(2): 1
      NAME(4): b
      INTPOS(2): 1
   INTPOS(2): 5

Even when it may sound like this structure provides an explanation, there are other cases (some reported here time ago) where this information is not enough. So, with hidden things I am skeptic by default...

Note that Preben's explanation in terms of op is exactly what the documentation states in the subsection "3.15 Using Expressions" > "Substituting Subexpressions" of the Programming Guide, Chapter 3:

An alternative to the eval command is the subs command, which performs syntactic substitution. It computes the expression as a tree and replaces subexpressions in an expression with a new value. The subexpressions must be operands, as identified by the op command. Using the subs command is equivalent to performing a subsop operation for each occurrence of the subexpressions to be replaced.

So, what is wrong?

@Axel Vogt

Understanding it deeper requires access to kernel code and its documentation. Missing that, sadly, "grey" box methods may shed some light, like in this example, tracing subs:

> trace(subs):
> subs(a*b=4, abs(5*a*b));
execute subs, args = x = (`not`, hasassumptions), `@`(x)
execute subs, args = x = (`not`, hasassumptions), `@`(x)
execute subs, args = _Envsignum0 = 0, signum(a)
execute subs, args = x = (`not`, hasassumptions), `@`(x)
execute subs, args = x = (`not`, hasassumptions), `@`(x)
execute subs, args = _Envsignum0 = 0, signum(b)
execute subs, args = _Envsignum0 = 0, signum(a)
execute subs, args = _Envsignum0 = 0, signum(b)
execute subs, args = x = (`not`, hasassumptions), `@`(x)
execute subs, args = x = (`not`, hasassumptions), `@`(x)
execute subs, args = x = (`not`, hasassumptions), `@`(x)
execute subs, args = _Envsignum0 = 0, signum(a*b)
execute subs, args = _Envsignum0 = 0, signum(a*b)
execute subs, args = _Envsignum0 = 0, signum(a)
execute subs, args = _Envsignum0 = 0, signum(a)
execute subs, args = _Envsignum0 = 0, signum(b)
execute subs, args = _Envsignum0 = 0, signum(b)
execute subs, args = _Envsignum0 = 0, signum(a*b)
execute subs, args = a*b = 4, 5*abs(a*b)
                                    5 | 4 |

It shows that subs does make/causes a lot of work behind the scenes looking for assumptions and the like. In particular, automatic simplification may be involved at one or more points, explaining this undocumented behavior. But it may be just a bug :)

@Kitonum 

What should be the expected result? One possibility is Sw+w[n+1].