Should we add a ListSwap(...) or SwapName(...) or some other function to make this easier?
For what it's worth, IBM Lotus Notes has grappled with this for years. Notes handles multi-value fields/data by using a colon as a list item identifier. It works two-way. An outputted list is items separated by colons. Or, inputting items separated by colons tell the program it is a list.
Supposedly, Ray Ozzie (Notes' architect) chose a colon because it doesn't naturally appear very often in text values that might be part of a list. This lets users more freely use comma and semi-colon within data.
Unfortunately, Notes isn't entirely consistent, letting developers use comma and/or semi-colon as displayed/typable list delimiters for form fields, since users understand using a comma. But this fights with data like company names "JRiver, Inc. -- one data item or two?). Internally, the comma/semi-colon is discarded, replaced by the internal item colon delimiter (actually, not even by that, but that's what programmers see and use).
This makes it fairly straightforward to manipulate data at various levels. With the entire list item delimited by colon, within an item lastname, firstname can be flipped around by just looking for comma or semi-colon, whatever the user prefers. (Developers learn the hard way which to let the user use.)
In MC, semi-colons are used in the UI for list items, and commas are tolerated within items. But there's the challenge of lastname, firstname vs. Peter, Paul & Mary, et al.
Perhaps MC can toss the colon into the plumbing as the explicit list item delimiter (such as in Keywords and other list-type fields), freeing up comma and semi-colon for use within data. If so, at a user's preference, comma could be used for natural data (Peter, Paul & Mary), semi-colon could be used for lastname;firstname, and in expressions/API colon would be used for multi-value lists (Peter, Paul & Mary : Police : Presley; Elvis : Prince)
(Actually, in the above list Notes would have quotation marks delimiting the values; however, actual field/variable names would be handled as shown. Spaces around the colons are ignored allowing for more readable code. Notes has a bunch of functions to manipulate lists.)
This could work because MC requires that a field be explicitly defined as a list or not. So even though a colon might be common in some fields (I use it in naming classical works, for instance), such a field isn't likely to be a list-type.