When I display generated filenames, .NET 10 numeric string sorting gives me the order people usually expect: file9.txt before file10.txt. The new CompareOptions.NumericOrdering flag handles digit runs without a handwritten natural-sort parser.
That sounds like a presentation-only change. It is not. The same comparer also decides whether two strings are equal, which can quietly collapse file2.txt and file02.txt inside a set or dictionary. I want both parts of that contract visible before I reuse the comparer across an application.
Why ordinary string order looks wrong
Ordinal comparison reads the characters from left to right. After the shared file prefix, the first digit in file10.txt is 1, so it sorts before the 9 in file9.txt. The comparer is behaving correctly; it simply does not interpret a run of digits as a number.
string[] fileNames =
