The LocaleMatcher completely ignores differences between equivalent (under addLikelySubtags()) locales. Example: en, en-US, en-Latn, en-Latn-US.
We see test cases (not sure about production code) where the supported locales include such "duplicates", and when those match, the matcher returns the first one listed.
In some cases, the tests expect a more precise match. That is, if the supported locales include both en and en-US, and the desired locale is one of these (before addLikelySubtags()), then they expect the "exact" match to be returned regardless of the order of supported locales.
See if this can be accommodated without causing other trouble.
done:
distinguish between equivalent but originally unequal locales
locale distance shifted left for additional fraction bits with micro distance
Java more verbose matcher debug output
Found warnings and an undefined-behavior bug during integration.
Found a performance regression.