Indeed, such change is required.

In that pde z and t are independent variables. So this ode cannot hold in general with z and t on the rhs and just t on the lhs. I.e. epsilon will depend on the value of z. So, the ode is actually a pde. Idem for the rest of the odes.

In that pde z and t are independent variables. So this ode cannot hold in general with z and t on the rhs and just t on the lhs. I.e. epsilon will depend on the value of z. So, the ode is actually a pde. Idem for the rest of the odes.

Consider e.g. ODE[1]:

diff(epsilon(t),t) = A[3]*exp(-E[3]/R/T(z,t))*(epsilonb-epsilon(t))

You have a function of t on the left and a function of z and t on the right. This equation cannot work in general.

Consider e.g. ODE[1]:

diff(epsilon(t),t) = A[3]*exp(-E[3]/R/T(z,t))*(epsilonb-epsilon(t))

You have a function of t on the left and a function of z and t on the right. This equation cannot work in general.

The impression that the tooltip "prepost" gives to me is also completely wrong (for the opposite reason, say). Instead of an atomic object like for other pallete items with textual tooltip I get a nonatomic one. But it may be a subjective issue.

More important, perhaps, is the other point that you raise: no reasonable pallete could provide all the typesetting options that may be required, and a programatic approach is needed. I mean something with TeXlike notation, not this Maple-mathml cryptic stuff.

By the way, the six names 'mscripts'  object that you post, is not the general beast in that the indices appear four on the right and one on the upperleft (and one appears missing), and you have also e.g. 'munderover' things and the like.

And what about the hybrid "prepost" thing:

`#mscripts(mi(\"A\",mathcolor = \"#00a050\"),
none(),none(),none(),none(),mi(\"b\",mathcolor = 
"#c800c8\"),mi(\"c\",mathcolor = \"#c800c8\"))`[d]^e

that is a  Maple-mathml, indexed name and `^` construction?

Note that you have both T(t,z) and T(z,t).

Note that you have both T(t,z) and T(z,t).

The problem is apparently 2D math input parsing (or design). The first statement converts to this 1D input:

(∂)/(∂ `ℛ`[0]) (-i*g[0]*(ln(mu)+1/
(`ℛ`[0])*(1-mu)));

I.e. it is not parsed as a 'diff' call as the second statement:

diff(-i*`#msub(mi("g"),mn("0"))`*(ln(mu)+(1-mu)/`ℛ`), 
`ℛ`);

My advise is to avoid 2D math input.

The problem is apparently 2D math input parsing (or design). The first statement converts to this 1D input:

(∂)/(∂ `ℛ`[0]) (-i*g[0]*(ln(mu)+1/
(`ℛ`[0])*(1-mu)));

I.e. it is not parsed as a 'diff' call as the second statement:

diff(-i*`#msub(mi("g"),mn("0"))`*(ln(mu)+(1-mu)/`ℛ`), 
`ℛ`);

My advise is to avoid 2D math input.

I do not see a problem either with literal subscripted variables. E.g.:

diff(y(`#msub(mi("x"),mi("1"));`,
`#msub(mi("x"),mi("2"));`),
`#msub(mi("x"),mi("1"));`);

diff(y(x[`1`], x[`2`]), x[`1`])

diff(sin(`#msub(mi("x"),mi("1"));`)
*exp(`#msub(mi("x"),mi("2"));`),
`#msub(mi("x"),mi("1"));`);

cos(x[`1`])*exp(x[`2`])

I do not see a problem either with literal subscripted variables. E.g.:

diff(y(`#msub(mi("x"),mi("1"));`,
`#msub(mi("x"),mi("2"));`),
`#msub(mi("x"),mi("1"));`);

diff(y(x[`1`], x[`2`]), x[`1`])

diff(sin(`#msub(mi("x"),mi("1"));`)
*exp(`#msub(mi("x"),mi("2"));`),
`#msub(mi("x"),mi("1"));`);

cos(x[`1`])*exp(x[`2`])

Yes, most Maple commands return 'NULL'  (the null expression sequence) as output when they fail to produce an answer. And 'NULL' prints as nothing. The help pages of many of these commands are not very explicit on this point. But some of them do tell it. E.g. ?isolve > Description, states:

It returns the NULL value if either there are no integer solutions or Maple is unable to find the solutions.

On the other hand, boolean commands do return 'FAIL' when they fail (cf ?boolean).

Yes, most Maple commands return 'NULL'  (the null expression sequence) as output when they fail to produce an answer. And 'NULL' prints as nothing. The help pages of many of these commands are not very explicit on this point. But some of them do tell it. E.g. ?isolve > Description, states:

It returns the NULL value if either there are no integer solutions or Maple is unable to find the solutions.

On the other hand, boolean commands do return 'FAIL' when they fail (cf ?boolean).