Saxon

My initial suspicion was that this might be a question of which Unicode version is in use, but using tables generated from Unicode 4.0.0 as against Unicode 6.2.0 does not appear to give any difference in the results, and indeed inspection of the UnicodeData.txt file suggests no obvious difference between versions for the relevant characters.

What does seem relevant is that (taking an example) the entry for 1F0E in UnicodeData.txt shows a decomposition to 1F08 0342, where 1F08 itself can be further decomposed to 0391 0313. It looks as if the Saxon data tables generated from UnicodeData.txt don't take this double decomposition into account.

Note: The original Java code from the Unicode consortium on which the Java implementation is based has been withdrawn:

http://www.unicode.org/reports/tr15/Normalizer.html

It's therefore possible that the code contains bugs which have not been fixed.

It appears that Saxon 9.1 got this right. Saxon 9.1 generated the normalization data into a Java module UnicodeData.java rather than into the XML data file normalizationData.xml which is used in more recent releases.

Noted that in Saxon 9.1, decompose(codepoints-to-string((7944,834))) yields (913, 787, 834) whereas in 9.5, it yields (913, 834, 787). The failure to sort the modifiers into canonical order then causes a failure to compose the pairs during the composition phase.

Debugging shows that in 9.1, data.canonicalClass(834) is 230, while in 9.5, the same expression returns 220. This seems to account for the difference in the result of the sort. 834 = 0x342, for which Unicode 3.0 UnicodeData.txt and subsequent versions all have

0342;COMBINING GREEK PERISPOMENI;Mn;230;NSM;;;;;N;;;;;

where the field 230 is the canonical class. So the data tables in 9.5 appear to be wrong.

There seems to be a problem with either the writing or the reading of the run-length-encoded CanonicalClassValues list, which was newly introduced when the change was made to put the data in XML format.