@Carl Love It may be broken again. Everything on MaplePrimes is unbearably slow right now. There are three new spam Questions (rather than the more-usual Posts) at the moment, 2 of which have spam Replies. I don't know if that's connected to this slowness

For what it's worth, I never close the help window. That's not because I think that I may have some problem reopening it, but rather because closing it seems to me (if I thought about it at all) like a totally unnecessary extra step. But actually it's never occurred to me to close it, although I've always been aware that that was possible, and it's a nuisance to me that I need to reopen it if my Maple crashes.

I'm not at my computer at the moment, but when I have a chance I'll check if I can duplicate what you described. I'm also using Windows 10.

@Carl Love Given procedure B above, the original formula B can be returned (for verification, among other things) by 

B([m||P]);

@Joe Riel If the Iterators can be meaningfully compiled with dummy input as you showed, then why not do that and store the compiled versions in the library during the overall installation of Maple?

@subzero The command op(k, f) will extract the k^th argument of function f. Note that f must be a function (i.e., it must have arguments) for this to work; it can't simply be a function's name as is the U in the example that you just posted. The command op(0, f) will extract the function's "name", which isn't always a name in the strict sense. For example, op(0, D(y)(0)) returns D(y). Another way to think about it is that op(0, f) is what remains after f​​​​'s argument sequence is removed.

If you have an expression e from which you want to extract all functions whose first argument is x, use

indets(e, patfunc(identical(x), anything))

@Joe Riel Joe, If you're looking at that SCR that I submitted last night regarding the kernel crash, I have very significant additional information about it, which I'll email to you if you want. My evidence proves that the bug is specific to the combination of add and Iterator, that eval has nothing to do with it, and that the compilation is only tangentially related to it (the compilation leads to the kernel crash, but the underlying bug occurs regardless of compilation). However, my evidence suggests that the culprit is Maple 2021 changes to add, which may not be something that you work on.

@Ronan I don't think that using startup code would help because compilation happens for each use by default. [Edit: Joe has just said below that due to a recent change, the startup code actually will help.] But, for the small sizes of the cartesian products that we're dealing with here, the effort of compilation isn't worth it, and it can be turned off. Compare:

restart:
B:= (2*m2 + 3*m3 + 4*m4)!*c0^(1 + m2 + 2*m3 + 3*m4)*c2^m2*c3^m3*c4^m4
    /((1 + m2 + 2*m3 + 3*m4)!*m2!*m3!*m4!*c1^(2*m2 + 3*m3 + 4*m4 + 1))
:
P:= 4: M:= [m||(2..P)]: N:= 4:
CodeTools:-Usage(
    seq[reduce= `+`](
        eval(B, M=~ [seq](c)), 
        c= Iterator:-CartesianProduct([$0..N]$(P-1))
    )
):
memory used=13.48MiB, alloc change=35.01MiB, 
cpu time=203.00ms, real time=205.00ms, gc time=0ns

restart:
B:= (2*m2 + 3*m3 + 4*m4)!*c0^(1 + m2 + 2*m3 + 3*m4)*c2^m2*c3^m3*c4^m4
    /((1 + m2 + 2*m3 + 3*m4)!*m2!*m3!*m4!*c1^(2*m2 + 3*m3 + 4*m4 + 1))
:
P:= 4: M:= [m||(2..P)]: N:= 4:
CodeTools:-Usage(
    seq[reduce= `+`](
        eval(B, M=~ [seq](c)), 
        c= Iterator:-CartesianProduct([$0..N]$(P-1), compile= false)
    )
):
memory used=2.48MiB, alloc change=0 bytes, 
cpu time=31.00ms, real time=23.00ms, gc time=0ns

One may wonder why I chose a new-fangled embedded for-loop for the above Answer when an old-fashioned add command with an index variable would've been shorter and more to the point. The reason is that in Maple 2021 (only), the following gives a kernel crash:

restart:
B:= (2*m2 + 3*m3 + 4*m4)!*c0^(1 + m2 + 2*m3 + 3*m4)*c2^m2*c3^m3*c4^m4
    /((1 + m2 + 2*m3 + 3*m4)!*m2!*m3!*m4!*c1^(2*m2 + 3*m3 + 4*m4 + 1))
:
P:= 4: M:= [m||(2..P)]: N:= 4:
add(eval(B, M=~ [seq](c)), c= Iterator:-CartesianProduct([$0..N]$(P-1))); 

I have formally reported this bug. However, this bug is not manifested by the OP's slightly simpler expression A.

Delete As Spam seems to be working now.

@acer Yes, I understand, and if it were my code, I'd use add. Like you, I don't understand why inert Sum is being translated as it is, and I'd prefer it to be translated as inert; that just seems to be the way that it currently is (which is usually the basis for my Answers).

@subzero I think that you may find these examples useful:

e:= u(x,y) + u(0,y) + sin(x);
indets(e, function);
indets(e, function(name));
indets(e, And(function, Not(typefunc(mathfunc))));
indets(e, And(function(name), Not(typefunc(mathfunc))));

If you have an older version of Maple, the last two of those may given you an error. In that case, replace typefunc(mathfunc) with typefunc(anything, mathfunc).

@Thomas Richard @acer Thank you both; you've answered my Question.

@Axel Vogt Yes, ordinary deletion works as a stop-gap measure; however, we've learned the hard way here that it's ineffective as a long-term solution to the spam problem. I'm surprised that the Delete As Spam option has been quite effective.

@subzero

indets(e, function) 

@Maplestudent 

By the way, I don't have the foggiest idea what your intention was with the line
if i=1 then k:= k+1 end if
but nothing like that is needed. Possibly it'd be educationally worthwhile for you to try to explain that to me.

@pik1432 I agree with Tom that all of the parametric 2D plots that you show are correct, that they are as you originally specified, and that they all show a single curve rather than 2 curves as you claim. Note that all of your expressions named i_armature... become extremely simple after they are simplified. I suspect that this may be the root cause of your inability to see that these plots are correct.