@Bland3 I am guessing that one of your requirements is the ability to have the nested sucscripting show with descreasing font sizes. (Coincidentally, I had just showed a method for that to someone else two days ago.)

I have written procedures that allow programmatic control over typesetting expressions (and even mixed math and text). I have done that in Answers in this forum, from scratch, a few times, as has Carl Love. Rather than duplicate the efforts from scratch, it might suffices to find some of the best prior responses, merge, and utilize to handle your own example(s). It'll take me a whirl, to locate and sift through.

Automatically decreasing font size for subscript-nesting might be new, though.

Yes, it is possible to do typesetting (within plots, or just as 2D Output) where there is control over the font size and color directly within the expressions and plotting "labels" themselves. (I'm not talking here about any new LaTeX importer, naturally.)  I'll try to come back to this soon, but busy right now...

@Carl Love Perhaps PDF export could be made to work. I don't really know enough to say.

But, even with some warts, I'd still like to get back the old inlining, and have that be the top priority. I especially liked that 1D input lines could be copied properly.

@Carl Love I'm going to try and ping the admins by email, about the worksheet inlining issue. I agree, it is very important to this forum.

My limited understanding is that this site uses (or did use) MapleNet technology for rendering worksheets. I believe that for a long time it was stuck back at an old version of that technology.

I know that there has been improvement to how the Maple Cloud renders worksheets. I would like to see an investment of development in improving this forum, including not only fixing worksheet inlining but improving it also.

I agree with you, that hearing different points of view on topics like this Question can help understanding. I'm glad you answered.

@Carl Love Yes, your examples and explanation reproduces most of what I had in my attachments and comments.

There is one minor wrinkle which your posted code does not account for, directly. The OP's goal is to call his ValveLaminarMassFlow_proc once more, at the computed root, and take the second value from its return value (of an expression sequence). His original choice was to make f an easy mechanism to get that value too. Hence my followup suggestion (in which like you I too had made f return unevaluated using 'procname' when x was not of type numeric) to allow f to accept the index as second argument. And I had it return both arguments in the unevaluated 'procname' call, to preserve the call appropriately.

There is one more wrinkle which I avoided describing in detail. The problem with premature evaluation of the call f(x) (within the original f(x)[1]=x argument passed to fsolve) can usually also be accomodated using uneval quotes. That works in the OP's worksheet if Units:-Simple is not loaded, but does not work directly if it is loaded. I didn't think that it would be to the OP's great benefit to discuss that problem variant in gory detail.

@rquirt Here are some more details.

Premature evaluation of a function call -- when passed as an argument to another procedure -- is a frequently encountered difficulty for new users. The error you encountered is common enough that it got its own Help page.

If you click on the magenta error message (which is in fact linked, as a URL) in your Document then your web browser can take you directly to this web page.

There are a number of straightforward ways that can usually be utilized to work around the issue. Some are described on that web page.

Another important workaround method is to rewrite your procedure f so that it returns unevaluated when its own passed argument x is not of type numeric. In other words, to rewrite f so that the call f(x) returns just f(x) itself, when x is just a name. Here is that approach, done for your Document.
   fsolve_if_then_not_evaluating_in_proc_ac_numeric.mw

Note that I also put the indexing of the expression sequence results from ValveLaminarMassFlow_proc inside procedure f, to prevent some internal confusion due to having Units:-Simple loaded.

[edit] I amended this, to make the indexing be done using an additional parameter on the f procedure. This allows f(answer, 2) to return 123.4183429 where answer is the root obtained from fsolve.

@grad_stu These names are options to the kernelopts command, which describes them to some extent.

Yes, the Help page for the CodeTools:-Usage command doesn't describe the terms very well (though it does have a cross-reference to kernelopts).

The call kernelopts(bytesalloc) provides a snapshot.

In modern Maple a garbage collection can sometimes free memory back to the OS. Since CodeTools:-Usage reports a start-to-end difference for bytesalloc the number reported may be negative in the case that more memory was freed than allocated during the computation.

Peak memory allocation is one possible way to represent OS memory use, but it's not the only meaningful number and it certainly doesn't tell a complete story about allocation over the duration of a computation. No single number can.

@adel-00 I will mention that -- because your code has no comments, and you gave no description -- I have very little idea what it's supposed to do.

In particular, lines such as,
    sum1[n]:=2*(L[n]+sum1[n-1])/3;
seem strange to me. I suspect that it doesn't do what you think it does, because the 2/3 factor is multiplied repeatedly against the earlier L[i] values. It's not just a simple summation.

So I'm going to exclude any multiplicative factors below. You can put them in, if you're certain you know what they mean and do.

You don't have to add up (all, or just some) of the L[i] while inside the loop. You can easily do that afterwards as well, using whatever formulas you choose. For example,

#odds := seq(2*n-1, n=-4..5);
for i from -4 to 5 do
  sumodd[i] := add(L[2*n-1], n=-4..i);
end do:

#plot([seq([d[i], Re(sumodd[i])], i=-4..5)],color=black);

#evens := seq(2*n, n=-5..5);
for i from -5 to 5 do
  sumeven[i] := add(L[2*n], n=-5..i);
end do:

#plot([seq([d[i], Re(sumeven[i])], i=-5..5)],color=black);

new_acc.mw

It's not clear (to me) that any of the code is doing what you expect. I suggest you go over it carefully.

@tomleslie Yes, replacing vector by Vector in the attachment I gave (listsetvector.mw) shows behaviour that had been recognized and mentioned, more than once before, in the discussion. The prior mention is why I omitted it from the attachment above.

Specifically, it demonstrates that a Vector does not have last-name evaluation -- which is thus seen to neither the cause nor the cure of the central issue. While the default column Vector gets its entries printed vertically and a lowercase vector gets them printed horizontally, both show the name of the assigned parameter.

And so it is evident that having last-name evaluation (or lacking it) is not the cause (or the cure) of the printing issue. It is only tangentially connected to the central issue, and a red herring here.

Upload and attach your actual Worksheet or Document that in which plots:-display fails to do what you want.

Then describe clearly what is wrong with it, if the problem is not a runtime error.

Why do you include text with expressions using apparently incorrect syntax, in your Question and at least one followup response? That adds to the confusion here, I think.

This characterization of the problem -- as being due to lack of last-name evaluation -- is incorrect. That comprises much of this Answer.

The fact that a Vector does not have last-name evaluation is not why it does not print as the OP wants or expects. The list and the set data structures also do not have last-name evaluation, but they do not have the unwanted printing behavior (ie. unwanted by the OP). And a lowercase table-based vector has last-name evaluation, but it too has the key, unwanted part of this printing behaviour.

The printing behavior not wanted by the OP is due neither to the presence nor absence of last-name evaluation on the structure.

restart;

L := [-2+m,3+m];
                      L := [-2 + m, 3 + m]

S := {-2+m,3+m};
                      S := {-2 + m, 3 + m}

v := vector([-2+m,3+m]);
                      v := [-2 + m, 3 + m]

m := 5;
                             m := 5

# absence of last-name evaluation
L;
                             [3, 8]

# absence of last-name evaluation
S;
                             {3, 8}

# last-name evaluation
v;
                               v

print(v);
                        [-2 + m, 3 + m]

v[1], v[2];
                              3, 8

listsetecwtorv.m

A Vector (capitalized V) also does not have last-name evaluation. But it does have the printing behaviour unwanted by the OP. Hence that quality neither causes the problem not does its absence avoid it. Your characterization that last-name evaluation is the factor of primary concern here is quite wrong and muddled.

@taro The third argument passed to the collect command acts separately on each of the "coefficients" (by which I mean, coefficients of the collected expressions, ie. coefficient subexpressions).

Take your expression,

restart;
c := I__11*I__22 - I__11*X__2 - I__12*I__21 - I__22*X__1 + X__1*X__2;

    c := I__11 I__22 - I__11 X__2 - I__12 I__21
         - I__22 X__1 + X__1 X__2

Let's pass just some dummy name K as the third agument. Look at the resulting separate calls to K, which are now the separate coefficients of the (powers of the) collected I__12 term.

collect(c, [I__12], K);

     K(-I__21) I__12
     + K(I__11 I__22 - I__11 X__2 - I__22 X__1 + X__1 X__2)

When we pass simplify instead of K for that third argument, the simplify acts separately on those coefficients (ie. coefficient subexpressions).

collect(c, [I__12], simplify);

     -I__12 I__21
     + (X__2 - I__22) (X__1 - I__11)

But when you do the following the simplify acts on the whole result of the first call to collect. And that allows the various subterms in the coefficients to affect the overall simplification -- which destroys the desired effect. The simplifications are no longer being done separately on the coefficient subexpressions.

collect(c, [I__12]);

  I__11 I__22 - I__11 X__2 - I__12 I__21 - I__22 X__1 + X__1 X__2

simplify(%);

  (-X__2 + I__22) I__11 + X__1 X__2 - I__22 X__1 - I__12 I__21

@Carl Love Sorry, typo, corrected.

@mmcdara We've been in this vicinity before, I think, discussing procedures that generate names that render as 2D pretty-printed output with subscripts.

Note that the second of these examples renders with the subscript in upright Roman, as opposed to the more usual italic for 2D pretty-printed names. Of course, you can adjust that, or mix and match.

The first two procedures produce the kind of name you've been calling "MathML". 

mmlsub1 := (x,s) -> nprintf(`#msub(mi(\"%a\"),mi(\"%a\"));`, x, s):
mmlsub2 := (x,s) -> nprintf(`#msub(mi(\"%a\"),mn(\"%a\"));`, x, s):
mmlsub3 := (x,s) -> cat(x,':-`__`',s):

mmlsub1( F, [a,b] );
mmlsub2( F, [a,b] );
mmlsub3( F, [a,b] );

Other variants are possible. Sophisticated handling of more ununusual objects in the subscript is also possible.