munder, mover, munderover: needs clarity in spec and consistency in implementation

The spec says:

The in-flow children are laid out using the algorithm for stretching operators along the inline axis.

That algorithm is:

The algorithm for stretching operators along the inline axis is as follows.

1. If there is an inline stretch size constraint or block stretch size constraint then the element being laid out is an embellished operator. Layout the base with the same stretch size constraint.
2. Split the list of in-flow children that have not been laid out yet into a first list LToStretch containing embellished operators with a stretchy property and inline stretch axis ; and a second list L_NotToStretch.
3. Perform layout without any stretch size constraint on all the items of L_NotToStretch. If LToStretch is empty then stop. If L_NotToStretch is empty, perform layout with stretch size constraint 0 on all the items of L_ToStretch.
4. Calculate the target size T to the maximum inline size of the margin boxes of child boxes that have been laid out in the previous step.
5. Layout or relayout all the elements of L_ToStretch with inline stretch size constraint T.

I believe the text means that if both stretchy and non-stretchy elements exists, then after computing all the sizes of the children of the mover element (etc) in the non-stretch conditions, then stretch the stretchy chars to fill up the extra space. The text for '5' however says relayout the elements of L_ToStretch with the size constraint T. However, it should be that each child of mover (etc) has size constraint T and the size constraint for the elements of L_ToStretch is more complicated.

However, I'm not sure that is really what is desired and in fact, the implementations seems to be inconsistent. Here is a codepen to illustrate some differences. The following shows what happens in Chrome:

The first example illustrates the easy case where we expect the arrow to stretch to cover the base. The second arrow mixes an identifier with the stretchy arrow. In this case, the arrow doesn't stretch which seems to be different from what the spec says should happen. The third case changes the mi to an mspace. Now the arrow stretches the full width and ends up being shifted right because of the mspace. This seems to follow what the spec says, but I believe is not at all what people expect.

I think the size constraint should be that the remaining space for each child of mover (etc) is divided the number of elements in L_ToStreach for the child.

Bottom line: I think the spec is wrong and should be adjusted. But it also appears that the Chrome implementation doesn't follow the spec in all cases.

Other browsers:

• Firefox behaves like Chrome
• Edge and Safari never stretch the arrow (I don't think it is a font issue)

Start with the MathML Core stretching-operators algorithm quoted in the issue and reproduce the linked CodePen cases. Compare the stated behavior with Chrome, Firefox, Edge, and Safari, then clarify the intended size constraints and update the specification once the cross-browser behavior and desired outcome are resolved.