It would seem that if the normalization functions worked to that spec, then they would always produce the same output order. However, in my limited experience I've never seen any real-world cases where you'd want or need multiple COMBINING characters... not saying it doesn't exist but the Unicode docs don't obviously mention it specifically.

I would say that if you're straying outside the defined normalization routines, that you gotta do something stable and predictable, like sort your multiple COMBINING elements into numerical codepoint order. (Order of these should never matter for the grapheme, right?)

Update: http://useless-factor.blogspot.com/2007/07/unicode-implementers-guide-part-2.html This blog says ordering does matter, and that they should be sorted by class of combining element. The ordering of combining elements in the same class may or may not need to be maintained, which is the issue you're running into. Pretty annoying if there's not a standard library implementation of all this.

My perlish hat says that to compare two graphemes, you'd have to do a hash/set of included characters, then compare the hashes for equivalence. If those match, and the order of combining classes is the same, it's the same grapheme.