Why is a subscript set in roman font placed differently

Question

Consider the following MWE:

\documentclass{article}
\RequirePackage{fontspec,unicode-math}
\setmainfont{STIX Two Text}
\setmathfont{STIX Two Math}
\begin{document}
\showboxbreadth\maxdimen
\showboxdepth\maxdimen
$\gamma_{e}\ne\gamma_{\mathrm{e}}\showlists$\showlists
\end{document}

It produces this output with LuaLaTeX:

As you can see, the two subscripts are placed differently.

The first \showlists contains no surprises:

### math mode entered at line 8
\mathord
.\fam0 𝛾
_\fam0 𝑒
\mathrel
.\fam0 ≠
\mathord
.\fam0 𝛾
_\fam4 e

But the second one does:

\mathon
\TU/STIXTwoMath(1)/m/n/10 𝛾
\kern-1.5
\hbox(3.6254+0.09818)x3.85008, shifted 2.09998, direction TLT
.\TU/STIXTwoMath(1)/m/n/7.01236 𝑒
\glue(\thickmuskip) 2.77771 plus 2.77771
\TU/STIXTwoMath(1)/m/n/10 ≠
\penalty 500
\glue(\thickmuskip) 2.77771 plus 2.77771
\TU/STIXTwoMath(1)/m/n/10 𝛾
\hbox(3.401+0.07013)x3.65373, shifted 2.09998, direction TLT
.\TU/STIXTwoText(1)/m/n/7.01236 e
\mathoff

Note the \kern-1.5, which tucks the subscript in under the gamma character on the left side, and the absence of a similar kern on the right side.

Why is this happening?

Edit: As egreg notes, this appears to be related to fonts – i.e., that the subscript comes from the text font and not the math font. Replacing \mathrm{e} by \symrm{e} cures it, in this case. However, if the subscript is a word, like “ess” or “disc”, this is not a good option, as the interletter spacing in the subscript is then wrong. Here is a workaround for that:

\Umathchardef\zwspace="0"0"200B
...
$\gamma_{\zwspace\mathrm{ess}}$

which adds a zero-width space from the math font as an ordinary math atom at the beginning of the subscript, allowing the normal subscript placement to take place. This has one shortcoming: If the next character is tall, that is not taken into account, and the subscript could be too far to the left.

I have reported this problem to the luatex list, and will report back here if I have some news from them.

Answer 1

Apparently, this has been fixed in the upcoming LuaTeX 1.08. (Source: Ulrike Fischer in chat.)

So it really seems to have been a LuaTeX bug (or at least, misfeature).