@dharr Yes, it's not clear why the OP wants atomic names for sub/superscripted expressions. My guess it that it might be to avoid any collision with the actual expression, but the OP really ought to clarify.

The third procedure in my Answer automates all generation of the atomic name which renders in 2D Output like the input expression, with minimal concatenation.

I agree with you that it's generally better to automate construction than to build up a complicated piece of MathML (or TypeMK, in undocumented Maple parlance). Natural exceptions are for cases where the 2D rendering doesn't actually match any valid Maple input expression, or when one wants special color/font/size.

Depending on one's view, one drawback here is that numerals are rendered in italics, which makes then look different from the usual expressions.  Eg,   x[5]^7  when normally typeset.

@MapleEnthusiast Alas, you have not actually answered my query as to what further computation you expect to do with this explicitly computed Matrix inverse.

@MapleEnthusiast What is the purpose of computing this inverse explicitly? For what particular further computation will it get used?

(I ask because this approach may be relatively poor -- some tasks like linear solving or least squares solving or eigen-calculation may be done better and generally more stably, numerically, with other, specialized techniques.)

Why don't you demonstrate why you think that the result is meaningless?

Have you noticed that the condition number of your Identity-A is about 8.3e9 ?

Addressing the followup,:

To plot the Vector V, interpreting its entries as uniformly spaced from a to b on the x-axis,

   plot(<<seq(a..b,(b-a)/(op(1,V)-1))>|V>);

and so, for V with 11 elements then to represent those on a plot from x=0..1,

   plot(<<seq(0..1,1/10)>|V>);

@Zeineb The detail that the data ranges from 0 to 1 on the x-axis is not present in the Vector, nor is it present elsewhere in your Question.

You have left out another detail: whether the Vector entries correspond to uniform placement along x=0..1.

@mmcdara You asked, "By the way, why doesn't Maple affect the type Vector to pf? id it because table is more general a type?"

It is because a table can be indexed by expressions other than just an integer, and so that behavior should be retained for backwards compatibility as well as broader generality.

@mmcdara The very first sentence of my Answer states that pf is a table.

That is a consequence of how the OP wrote his code. A preconstructed Vector is a decent alternative, but I stuck with what the OP had.

@Felipe_123 Do you mean like one of these, say?

PlotHistogram_2.mw

You could easily adjust the offset, if you want the bin numbers centered, or at left or right, etc.

You should run through what all these commands and options do. By familiarizing yourself with it, you'll be better able to customize it on your own in future.

Or you could construct a bar chart from the results from Statistics:-Histogram.

@markweitzman In Maple 2019.2 it doesn't bother with ftoc or ftocms once it gets that result from the meijergspecial method.

In Maple 2020.1 the internal mechanisms have been adjusted, and it continues for your example and tries ftoc and gets the simpler result.

You can see evidence of some of this by issuing these commands:

restart;
kernelopts(version);
infolevel[int]:=4:
int(2*Pi*x*sqrt(1+x^(-4/3)/9), x=0..1);

As previously mentioned, you can force method=ftoc or method=ftocms and get the simpler result from Maple 2019.2 as well.

Does your computation require the Grid Toolbox, rather than just the Grid package that is stock in Maple 2020, in order to compute with parallelization on your local multicore machine?

@robertocooper I have deleted a duplicate of this very Question (which merely showed another attempt at programming it). Don't split the Question and topic like that.

You can put your followup code in a new Reply here, or augment the Question body above and add it there.

@tomleslie I suspect that the Question is about discovering the particular identities of all the instances existing within some Document, of a given type of Embedded Component.

I don't think that the OP is asking about valid terms for referring to types of Components.

@Carl Love That's a very good point, thanks. I was hung up on the italics issue, which is not nearly as important.

However, I feel that the mechanism of assigning something (anything) to the problematic names is handy, but not great. It's a workaround.

It would better if the Typesetting package offered a configuration option for this. It has several similar things for special-function calls, relational operators, etc. It seems natural to me that it could also offer control for the Greek letters.