I think I got it, sort of.
If the same string shows up multiple times in the Display field, then MC will try to "group" all values it shows up as, for string fields that means it outputs "[Varies]" as the sort value.
If the Sort field is a numeric, it just averages the numbers, and sorting works as expected.
It works in the earlier examples mostly "by accident", because the list of files is already pre-sorted by the sort key, because both the pane and the list of files are sorted by the same thing.
In short, its not going to work, and I don't see a way to fix that. What sort key should "L" be assigned to, if it has two values? Can't exactly average strings...
It should behave sanely if there is *no* duplicates in your Display field, or all Display->Sort field mappings are exactly the same, then there won't be any [Varies] in the output.
Obviously the second condition might work if Sort is a field derived from Display through an expression, but only if its not a List field.
Take these files:
Display: "Foo Bar" -- Sort: "Bar, Foo"
Display: "Ham Eggs" -- Sort: "Eggs, Ham"
Display: "Foo Bar; Ham Eggs" -- Sort: "Bar, Foo; Eggs, Ham"
The first two alone would work fine, and the third breaks it.
MC cannot associate individual elements with each other, since it doesn't have any way to know the relation between two fields.
So if I'm looking up all possible Sort values for "Ham Eggs", I end up with "Eggs, Ham" and "Bar, Foo; Eggs, Ham" .. and what now? Which do I use for sorting? MCs solution is to respond with "[Varies]" in such a case for Strings.
I hope that makes it somewhat clear how this simply cannot work the way you hope it would, unless I'm missing something.
This is really the same reason why the group editing dialog doesn't have a way to specify any generic field as a sort field, because it just wouldn't work in the majority of cases for string fields.
It seems kinda odd that custom sort presets do show up there. Maybe I should remove them?