To me it looks like Gecko reset the current text position (to 0,0) on the (not at "after"; easily observable by replacing the textPath with a tspan with x=y=0). That seems to be closer to the last approach - albeit with a bug somewhere... (My guess would be an incorrect computation of the initial CTP.)

Edit: I see the Gecko behavior is now "documented" in the spec (step 10.2.1; https://svgwg.org/svg2-draft/text.html#ResolveGlyphPositioning)

RESOLUTION: text following textPath text is positioned as if the x,y is at the end point of the equivalent path

https://www.w3.org/2016/04/22-svg-minutes.html#resolution07

Note the equivalent path hasn't been written up yet, but see https://www.w3.org/2016/04/22-svg-minutes.html#resolution02.

Sorry for the late comment...

Wouldn't it be most logical that the x,y of "after" would be whatever the current text position was after the last character rendered on the path (ie. the "h")?

@BigBadaboom That was the other possibility we discussed, and seems to match the current Edge/Blink behavior. The Gecko behavior is definitely undesirable, and spec will be changed where it suggests that is correct.

The reason we resolved on using the end of the path, rather than the position of the last character, is that it would provide more precise author control, with less variability based on font, etc.

If other authors or implementers want to argue for keeping the Edge/Blink behavior, now would be the time.

Thanks for the explanation. I didn't see that point made in the minutes. It's a reasonable approach.

Fix committed: 780fb0f