I will mention one more, with a twist on doing it via definition.

This one also has the unexpanded (3*x^3+y^2)^2 subterms, as requested.

But the reason that I like this one is that --  when hit with simplify, say -- it does not produce those ugly numerator and denominator, both as sums with most terms involving radicals with fractional powers. And numer or denom of it produces the same as appear after applying either simplify or radnormal, which just the mentioned subterm getting expanded.

Download impldiff_alt.mw

Yet another way, without a kludge, and with a nicer form than I had above. (If isolate is replaced with solve and the rhs is removed, or if I don't first collect wrt diff, then the messier form attains.)

Download impdiffalt.mw

You have not included the equation.

@Kitonum The Generate(choose(...)) functionality is not fast, as used here. It's a little faster if the makeproc option is used. But it's still much slower than indexing by an integer generated via rand.

restart;
with(RandomTools):

LetList := [C, E, F, H, K, P, T, W, X, Y]:

[seq(Generate(choose(LetList)), i=1..5)];
                        [T, Y, P, E, H]

genR:=Generate(choose(LetList), makeproc):

genR();
                               P

[seq(genR(), i=1..5)];
                        [K, C, W, K, Y]

N:=10^5;
                          N := 100000

CodeTools:-Usage( [seq(Generate(choose(LetList)), i=1..N)] ):
memory used=252.55MiB, alloc change=32.00MiB, cpu time=1.71s, real time=1.71s, gc time=80.78ms

CodeTools:-Usage( [seq(genR(), i=1..N)] ):
memory used=165.57MiB, alloc change=0 bytes, cpu time=1.17s, real time=1.17s, gc time=56.40ms

gen:=rand(1..nops(LetList)):

CodeTools:-Usage( LetList[['gen()'$N]] ):
memory used=2.29MiB, alloc change=0.77MiB, cpu time=40.00ms, real time=40.00ms, gc time=0ns


CodeTools:-Usage( Generate(choose(LetList)), iterations=N ):
memory used=2.61KiB, alloc change=0 bytes, cpu time=17.28us, real time=17.29us, gc time=8.6e+02ns

CodeTools:-Usage( genR(), iterations=N ):
memory used=1.72KiB, alloc change=0 bytes, cpu time=12.08us, real time=12.09us, gc time=5.1e+02ns

CodeTools:-Usage( gen(), iterations=N ):
memory used=32 bytes, alloc change=0 bytes, cpu time=6.0e+02ns, real time=6.0e+02ns, gc time=0ns

I would expect that a more runtime-efficient way to construct these Matrices (if that really matters much to the OP) would be through repeated used of ArrayTools:-BlockCopy.  That avoids construction of the rows as lists of sequences of duplicate copies of L and F, which is just temporary/collectible garbage.

Likely even more efficient than that would be repeated assignment of just the nonzero entries of sparse F and L into the target Matrix.

I answered in terms of Matrix(..., scan=triangular[upper]) because it seems simple and clear. And the way the rows are constructed is very much like the OP's construction of the bands in his call to BandMatrix for L, by simple use of seq.

Do you think that the consequences of such a change in behavior would be limited to, "just a little overhead"?

There are at least two actions here, both of which may take place in `^` which is a kernel built-in: splitting (2*Pi)^(1/2) and rationalizing the denominator in 1/2^(1/2) .  I don't see why changing either of those canonicalizations might not bring about unexpected changes in functionality or performance.

I really, really don't like customizable, computational preferences with such a low-level effect. Every time a new one is added the cost of an exhaustive regression- and unit-test run (against all combinations of all such kind of preferences) will likely nearly double.  There are now enough such preferences that the cost of a frequently scheduled, exhaustive test run must surely be prohibitive. And hence the consequence of adding such a new preference is the added risk that some computations will fail under some configurations without anyone discovering it before conflicting examples take root.

Since the OP asked about what formulas Maple might access, there is also this:

  map(print, FunctionAdvisor(hypergeom, quiet, "special_values")):

or, paying attention to the "special values" section which is produced in Maple 2018,

  FunctionAdvisor(hypergeom);

There are also somewhat brief help-pages for Topics convert,GAMMA_related and simplify,hypergeom and convert,StandardFunctions . The help page for Topic hypergeom mentions the last of those in its description.

The knowledge in FunctionAdvisor and in convert and simplify are related, but I suspect that it is a considerable ongoing task to put the mechanisms, knowledge, and documentation in optimal order.

In the rare times that I've needed to, it's been possible to extract programmatically a particular formula out of FunctionAdvisor's return, and then use it to effect a replacement.

Ok, it looks as if you entered x^2+5-2 presumably in 2D Input mode.

But there are a few other configuration options that might be affecting this. For example, do you have a language pack installed? What typesetting level is your default?

Did you type all the input from the keyboard, or did you use any of the palettes or command-completion?

It would probably be helpful if you could upload short Worksheet/Document that illustrated (just) the problem, as well as answered the above queries.

@digerdiga Try it as,

frontend~(expand,`[]`~(o))
 

@digerdiga Where did you get the idea that the following will apply both simplify and combine to the collected coefficients?  (If it's due to something I once wrote, then it was likely a mistake I missed in haste.)

   collect(f,[k,GAMMA],simplify,combine)

Please compare,

restart;
kernelopts(version);

    Maple 2018.1, X86 64 LINUX, Jun 8 2018, Build ID 1321769

collect( 1+x+x^2, x, K );

                          2                
                    K(1) x  + K(1) x + K(1)

collect( 1+x+x^2, x, K, W ); # no application of K

                          2                
                    W(1) x  + W(1) x + W(1)

collect( 1+x+x^2, x, W@K );

                         2                      
                W(K(1)) x  + W(K(1)) x + W(K(1))

collect( 1+x+x^2, x, u->W(K(u)) );

                         2                      
                W(K(1)) x  + W(K(1)) x + W(K(1))

And for your example these two produce the same thing,

collect(numer(f),[k,GAMMA],u->simplify(u/denom(f)));

collect(numer(f),[k,GAMMA],simplify@(u->u/denom(f)));

@digerdiga Please explain precisely what you mean, and if in doubt upload a worksheet that illustrates the problem clearly.

Download collect_numer_2015.mw

Don't try and insert the contents of your file here. Just insert a link to the uploaded file.

Hit the OK button as the last step in the pop-up dialog, after inserting the link.

If that all fails then try it with a compressed .zip file.

It works for me in Maple 18.02.  (I corrected the obvious syntax mistake 2*x instead of 2x .)

Consider uploading a worksheet that demonstrates the problem.

If you are using 2D Input mode then don't paste code in as plaintext here if it's not valid 1D Maple Notation. Otherwise it's confusing. Uploading a worksheet is key if your problem is 2D Input specific.

Please upload the worksheet.

Do you understand that the expression is not zero for all real phi?