This is definitely possible to do now, and I've discussed strategies for doing so a few times (though mine are often centered around Artist, Actors, and other similar auto-filled fields).
If you already have the field filled in Firstname Lastname format, you can build a sort-field you can use in various places with one simple "checkbox" Field and an expression.
There are issues with it, if you want to be able to tag or view them in name-swapped order, but if you
only want to sort-by the swapped order (and continue to view and edit everything in "normal order") then you're fine to use this.
Make an Override FieldFirst thing you need is a simple boolean field you can set to allow you to override your normal sort-behavior (for edge case names that don't get "swapped" properly). So, you can name it as you see fit, of course, but you want basically this:
Field Name: Composer Sort Override
Field Type: User data
Data Type: Integer
Relational: Store one value for each composer
Edit Type: Check
Acceptable Values: 0;1
Save in File Tags (when possible): Up to you, I'd do on so you don't have to re-do it for re-imports, but 🤷♂️.
Show a Link Checkbox: Off
Make a Field to Use for SortingNow, make a second new field. This one is going to be a Calculated Data type Field:
Field Name: Composer (Sort)
Field Type: Calculated Field
Edit Type: Cannot Be Edited
Show a link checkbox: Probably not.
Expression:
If([Composer Sort Override],[Composer],Swap([Composer]))
Then, you use [Composer (Sort)] to sort anywhere you'd have previously sorted the Composer field. You continue to display the Composer field everywhere in your views (you never look at the [Composer (Sort)] field columns or anything, except when testing), but you sort your stuff using it. You can sort the Categories too. Simply save a Sorting Preset with your [Composer (Sort)] field, and then any time you add [Composer] as a field, sort it by this preset instead of "Ascending" or "Descending".
The built-in Swap() and Unswap() function does know about
some name suffixes (like Jr. and III) and it might even handle common prefixes like "von" as mentioned by wer above. Or, I suppose you could include them as articles in the articles list and attack it that way. If you have a lot of edge cases for which Swap() doesn't work of a particular type, you can just special case them with IfCase() or additional nested If() statements in the [Composer (Sort)] expression to "fix" those particular cases.
However, the [Composer Sort Override] checkbox is your release valve. If you check that box, it "overrides" the normal expression behavior and passes through the original text of the [Composer] field. The nice thing is, since you can make [Composer Sort Override] a relational field on [Composer] then you only need to check one instance of the particular composer's name to override. So, if you have any particular composer for whom the Swap() behavior doesn't work, tag the [Composer] field on just
those files however needed to get them to sort correctly, and then check the box. You only have to check the box once, on one file, and then
any file with that [Composer] value will be treated properly automatically (even future files).
Alternative Composer Sort Override MethodThat's the simplest mode. If you don't like that you have to see those "specially tagged" files in the [Composer] field with possibly ugly-looking text (which won't "match" the rest of the data stored in [Composer]) for those Overriden composers, then you change the [Composer Sort Override] from a boolean field to a string field:
Field Name: Composer Sort Override
Field Type: User data
Data Type: String
Relational: Store one value for each composer
Edit Type: Standard
Acceptable Values: <empty>
Save in File Tags (when possible): Up to you, I'd do on so you don't have to re-do it for re-imports, but 🤷♂️.
Show a Link Checkbox: Up to you.
That's effectively what dtc suggested above. Then, you use it just like the checkbox version above, but instead, you type in what you'd like to override it with in this field (instead of just checking a checkbox). Then you just tweak the expression in [Composer (Sort)] to do
If(IsEmpty([Composer Sort Override]) instead. That way, you don't have to look at the "ugly". The only downside is that you give up the simplicity of checking a box to pass-through names which are "already right" in [Composer] as they are now. I'd think that
might be the more common failure case for Swap(), single-named people and whatnot, but you'd have to see how it worked out in your Library, and how willing you'd be to fix other special cases in the Expression. There's also the further downside that you have to remember to change the text in two places if you change a [Composer] value in the future (in the real field, and then in the corresponding [Composer Sort Override] field for at least one of those files afterwards). The Checkbox method doesn't have that downfall.
And, if you're perhaps a bit too clever, you could do it with three fields and combine both approaches. But that's likely more trouble than it is worth in ease-of-use and setup effort.
All of that should work just fine. The only issue is if you want to use that [Composer (Sort)] field as a Category and Column in your Views directly (so they look like they should sort in the order they do). That is difficult or impossible currently if you want to use those Columns or Categories to tag files, effectively replacing the "underlying" [Composer] tag. You can't do that, which is why I asked for the Writable Calculated Fields feature, but none of the versions of that idea we came up with in the other thread have been implemented.
So, for now, if you do it, you're stuck viewing [Composer] as it is, but if that is okay with you, you can sort it however you'd like.