I’m not getting into whether we can change the prioritization from the adopted resolution, which needs to be looked at, but regarding the idea I believe the issue is the selection of the initial letter. IDNs can be solved by applying prioritization to the A-Label (not the Unicode version) of the transposed string, just like Werner suggested. So if the string is 點看 (“click to see”), the A-Label is xn—c1yn36f and the prioritization token would be f63ny1c (removing xn— . But we should also reverse ASCII strings, not just IDN ones, due to getting more dispersion of tokens. Since the report foresaw not mingling ASCII priorities with IDN priorities, this allows to not compare an IDN token to an ASCII token. This would suffer due to presence of digits in IDN A-Labels, which are not allowed in ASCII by the program rules, but that problem is not applicable due to hard separation of priorities. We should note that this system would allow some prioritization results to be shared among applications, like applications to the same string (elpmaxe for .example, example, .example etc.). But that’s not a bad thing, since one of the 2012 issues was exactly when a contention set was spread by very different priority levels. This can still happen, though, because of indirect contention; but it will happen much less. (BTW, this also fits nicely for prioritization in the name collision analysis process). As for the initial letter (which would be the end letter of the string) to go first, I suggest calling a psychic to pick one. A suggestion from a psychic is not random, it’s defined by other realms of the universe we don’t understand. Or, just picking I because it’s ICANN. That might favor languages with lots of words ending in I, like Italian, but not by much. Rubens