@mmcdara 
Just as a fun alternative,

Download for_fun.mw

Of course your mileage may vary, depending on expression.

I recall that (7.5 years ago) I wrote this.

I'm pretty sure that I've duplicated a similar thing (that also adjusts colors of fencing, etc) in several responses over the years.

It's all inter-related: MathML, Maple's Typesetting, etc.

However none of this helps directly with your original question (unless you are willing to accept a space denoting multiplication of H__2 or H[2] and O__2 or O[2], or to remove it in such mechanisms).

Even Robert's suggestion to manually form the concatenated name of a pair of symbols -- both having subscripts -- as an atomic identifier is not entirely straightforward. Backing up over a space between subscripted terms may be one step. Obtaining a result with upright Roman symbols is yet another step. And all as a one-off.

One of the strengths of a programming language is that such constructs can be built programmtically.

Download typemk_more.mw

@mmcdara If you lprint your example you should be able to detect that your problematic example has some hidden character or space in it.

Are you aware that you do not need to utilize any Code-Edit-Region in order to define a procedure?

You can also enter procedure definitions in a regular Execution Group.

You can even set the default entry mode to 1D (plaintext) Maple notation, rather that (typeset) 2D Input. You can also set the default for new sheets to Worksheet rather that Document.

@Axel Vogt It may be that inttrans:-fourier is splitting it, and then running into failure:

int(erf(x)*exp(-I*x*k),x = -infinity .. infinity):
lprint(%);
  -2*I*exp(-1/4*k^2)/k

int(erf(x)*cos(-I*x*k),x = -infinity .. infinity):
                     0

I*int(-erf(x)*sin(-I*x*k),x = -infinity .. infinity):
lprint(%);
  I*int(I*erf(x)*sinh(x*k),x = -infinity .. infinity)

The integrals involving erf(x)*cos(-I*x*k) and erf(x)*exp(-I*x*k) are handled successfully by method=meijergspecial.

This is an engaging read.

Readers who like this might also be interested in these old posts by John May: 1, 2, 3, 4, 5, 6.

@Magma I do not have access at this momemnt to a machine with enough RAM to complete your large example.

However, I have noticed something troubling about the performance on your smaller example (which I included in my first Comment) as shown by CodeTools:-Usage under 10 repeats.

Maple 2015.2 (or earlier, approx.)
Your BP:
memory used=41.43MiB, cpu time=229.70ms, real time=232.80ms, gc time=12.40ms
Carl's modified BP:
memory used=12.47MiB, cpu time=97.80ms, real time=97.80ms, gc time=4.41ms

Maple 2016.0 (or later, approx.)
Your BP:
memory used=193.62MiB, cpu time=1.03s, real time=990.50ms, gc time=96.95ms
Carl's modified BP:
memory used=152.51MiB, cpu time=783.60ms, real time=757.30ms, gc time=76.69ms

@Magma In order to get Carl's revised BP to behave the same (on the earlier example A) as your procedure BP in Maple 15 all I had to do was modify one instance of a call to seq (to not utilize the newer calling sequence seq(U) ).

Otherwise I simply copied and pasted as 1D input.

BP_15.mw

Did you have an (other) input example that was problematic?

@Christopher2222 In my opinion the iPhone is a far more interesting target than the Fire for an Arm port.

The Fire also has difficulties with installation of arbitrary programs as applications. That also applies (at present) to an x86-64 based Chromebook, although there is some mitigation for those who run a terminal shell in developer mode or who re-install with ubuntu, etc.

Another Arm platform that might interest some is the Raspberry Pi.

On a related topic, I am hoping that the worldwide cloud/thin-client craze will peter out, and that something as locally useful as plugins will re-emerge.

@Kitonum Indeed, all methods will suffer from the possible problem of prior uniquification by the kernel. Your last edit is another example of what I was showing: forcing the order in which the variables are used to complete-the-square is enough (but still will succomb if the unwanted form has been previously constructed).

Unfortunately I don't know how sort could be used to forcibly re-order the terms (as for some similar problems) because the target is not expanded.

Download zw2.mw

@Kitonum Your approach is not generally reliable -- it doesn't work if the alternate form has been formed beforehand in the same session.

Given the above weakness (to which Carl also alluded), there are easier ways to get the same effect.

Download zwisch.mw

@vv The persistence of those plot labels (up until output removal) in your example is intentionally designed GUI behavior, as I explained previously in my Answer. I do not much like that behavior, but it's neither new nor very mysterious.

Yet what is indeed buggy is that, in the OP's original example, axis labels from one plot got applied to another within the same execution group.

I conjecture that this might be an overlooked corner-case is the logical flow of the GUI code that handles "plot persistence". It might also relate to use of semicolons on assignment statements involving plots.

@mmcdara That's quite a different mechanism.

Plot inheritance (aka plot persistence) affects output of single execution groups (or document blocks) independently. It consists of the GUI automatically re-applying certain display qualities from a prior plotting output upon re-execution of the very same group/block. The effect does not transfer between groups/blocks. It can be cleared by removal of the output of the particular group/block.

What you're describing now is that interface settings are managed by the GUI (I for Interface) and within a GUI session are not reset by a restart. That affects multiple groups/blocks together.

It is somewhat related to the unfortunate fact that calls to interface should go in a separate group/block from calls to restart.

Are you trying to say that you want to avoid the overhead of three calls to Transpose (or any kind of copying)? I mean, are you trying to avoid any overhead incurred by, say,
    Transpose(LinearSolve(A^%T,b^%T),inplace)

How large is your Matrix? Are the entries all floats? Is b always a Vector? Does the Matrix have an indexing-function (ie, shape)?

Are you looking for a convenient syntax, or is high efficiency a primary concern?

In the floating-point case, are you concerned with possibly less accuracy from b.A^(-1)?

Here is a simpler example with only a single plot rather than an animation.

In the Classic interface of Maple 2019.0 (32bit Windows) the PLOT3D structure that contains two LIGHT substructures will render using both light sources together.

In the Standard GUI the renderer only uses one of the light sources. As far as I know this has always been the case.

When the plotting commands were retro-fitted to use the new keyword handling (?paramprocessing) any arguments of the form light=[...] got the new handling so that only the last instance gets utilized. This change came some time after Maple 7. Prior to that multiple instances of the light=[...] option were all utilized and the resulting PLOT3D structure contained the corresponding multiple LIGHT substructures (but only Classic would utilize them in rendering).

In summary:
1) The Standard GUI renders using only one of any LIGHT substructures found, even when there are several.
2) The Classic GUI (32bit Maple 2019 on MS-Windows) can still render using multiple LIGHT substructures, if they are present.
3) The parameter-processing of the plotting commands now ignores all but the last light=[...] keyword option, so there no longer is any convenient way to construct a 3D plot that contains multiple LIGHT substructures.

Here's an example that I did in Maple 2019.0, 32bit Classic on Windows 7. I have replaced the images, so that it renders here as it does in Classic. (In the Standard GUI the first plot, which contains both LIGHT substructures, renders the same as the third plot. The default orientation may differ from Classic, but that's not the point.)

>  restart; with(plots): with(plottools): P := display(sphere([0,0,0],1,color=gray,style=surface)): L1:=LIGHT(90, 40, 1, 0.5, 0.8): L2:=LIGHT(90, -80, 1, 0.2, 0.1): >  op(0,P)(op(P),L1,L2); >  op(0,P)(op(P),L1); >  op(0,P)(op(P),L2); >

Download multiplelights.mws