So apparently perl6 is also "wrong" and operates on codepoints, your system composed my original string and each (base, diacritic) pair was pasted as a single precomposed character (I expect that if you try out the Python version on your system you'll also get the "right" answer).
The new string is composed of 10 user-visible characters (5 character repeated twice) but 16 codepoints (and this time I carefully checked that there was no precomposed version):
DEVANAGARI LETTER DA
DEVANAGARI VOWEL SIGN E
DEVANAGARI LETTER VA
DEVANAGARI LETTER NA
DEVANAGARI VOWEL SIGN AA
DEVANAGARI LETTER GA
DEVANAGARI LETTER RA
DEVANAGARI VOWEL SIGN II
DEVANAGARI LETTER DA
DEVANAGARI VOWEL SIGN E
DEVANAGARI LETTER VA
DEVANAGARI LETTER NA
DEVANAGARI VOWEL SIGN AA
DEVANAGARI LETTER GA
DEVANAGARI LETTER RA
DEVANAGARI VOWEL SIGN II
Operating on codepoints, both versions cut after the second DEVANAGARI LETTER NA (न) breaking that grapheme cluster (it should be ना) and not displaying the final two clusters ग and री.
> So apparently perl6 is also "wrong" and operates on codepoints
Yes and no. Yes, because the in-development Rakudo compiler is clearly currently giving the wrong result, and no because it operates on grapheme clusters (but has bugs).
(You can work with codepoints if you really want to but the normal string/character functions that use the normal string type, Str, work -- or more accurately are supposed to work -- on the assumption that "character" == grapheme cluster; afaik it's supposed to match the Unicode default Extended Grapheme Cluster specification.)
Yeah you're right, a caveat in the docs says that current implementations aren't finished with this. I was under the impression the NFG work was done but I'll catch up with people on irc.
Python ignores grapheme cluster, that point was about my original test case using grapheme clusters I later found out had precomposed equivalent, so a transfer chain performing NFC would leave the test case with no combining characters (or multi-codepoint grapheme clusters) left in it.