Update: the /page/summary endpoint has changed in 1.3.2 to more comprehensively flatten anchor and span elements, when possible into text nodes. I think this issue should be significantly reduced now. We might consider applying the same strategy for the reading content versions.
I'm not closing this because the issue would still exists for direct users of Parsoid, though.

This appears to be the upstream bug: https://bugs.webkit.org/show_bug.cgi?id=172855

The problem seems to arise when (at least) one of the characters is written as an HTML entity, eg:

&#nnnn;o

Parsoid will wrap a <span> tag around the entity in order to support roundtripping, and that span tag will "separate" the combining character from the character it should apply to, in (broken versions of) webkit.

Two possible workarounds:

• drop the span if the wrapped entity is a combining character. That will make a dirty diff on roundtripping because the entity will be expanded in the wikitext, but selser should cover most of these cases in practice.
• expand the span to cover more than one character, roughly the same way we "expand the range" of templates.
• do nothing and wait for webkit to fix their bug: https://bugs.webkit.org/show_bug.cgi?id=6148

My recommendation is the first, which is probably one conditional in Parsoid plus importing a (hefty) npm library containing the unicode character class database to identify combining characters.