I should have included a warning about that one in my explanation for this question - the problem is that the comparison style returned by COLLATIONPROPERTY for a collation is not the Comparison Style used in comparing collations to order SQL_VARIANT values; in particular, it delivers 0 both for _BIN and for _BIN2 for all locales (despite these being generally quite distinct comparison styles), whereas variant puts these two just about at opposite ends of the scale (at second and last out of 18). Some of the other numbers it returns also fail to match up with the style number used in variant sorting (eg it returns 0 for _CS_AS_KS{_WS too). And I don't know whether this is a bug in the COLLATIONPROPERTY function; but as returning the same value - 0 - for two different styles is actually documented, I guess it's not a bug unless the documentation has a partially matching bug. Most probably it is just another failure of BoL to tell us what is actually going on. I also don't know what the integer comparison styles used by the SQL_VARIANT order are; just that their order matches the list I provided.

The Collation version returned by COLLATIONPROPERTY also differs from the LCID version used in sorting variants, as noted in the explanation of the previous question in this series, but that of course is fair enough - it's a collation version, not a locale version. The issue you have hit on is rather nastier.

Incidentally, sort ID is something that old-fashioned SQL collations (collation name beginning SQL_) had, and can be derived somehow for Windows collations (Windows collations may once have had it; I don't think modern ones do) to help people understand how to maintain compatability with databases which used older collations. I don't think it comes into the ordering of windows collations used in SQL_VARIANT at all (but I may be wrong - the documentation says it does, as you point out - it says sort ID is compared, not sort ID is compared if it exists).