I don't object to the suggested proposal. But if this is the route to go, how would fields be displayed in mp3tag when simply browsing files? Something needs to indicate in the tag panel and list view where there are multi value fields. The current \\ method is clear. Perhaps some other character combination can be used, but inevitably there will be another clash at some point.
If I could make a wish, I would suggest to let the user choose the displayed dividing character that represents the technical and invisible zero byte. As default the \\ could remain as displaying character. Others could optionally choose some other - even a Unicode - character.
I have had this same discussion recently with another music service I use for my uPnP server. Perhaps these differences may align in the near future!
You are right: as long as printable characters are used, some ingenious artist will use that as part of the title. So, in a way, the problem will only move to that user-defined character but will not be avoided altogether.
If the problem is taken seriously, then IMHO, an extra effort has to be spent to make clear what has been inserted by the program (which could mean that these separators cannot be edited in the gui display and the cursor always jumps over these separating characters) and what is part of the data.
Considering that some solutions date back to the times when CDs where the prime medium for audio data and probably no unpronounceable characters where used in the track descriptions, it could be that the concept from those days has to be revised which would also lead to a revised concept of how to display this kind of data.
All great points and suggestions here. This has been a very productive thread. Hopefully some of these make there way into future development.
If we could disable automatic splitting based on the \\ sequence when saving as previously suggested, we could enable it when we want, or temporarily enable it by pressing, for example, Ctrl + Return on a field's value which would then be parsed for any double backslashes and split accordingly. If automatic splitting were enabled, the behaviour would be as it currently is, no Ctrl modifier needed.
Since scripts write the data (save) after fetching it, with automatic splitting disabled, any fetched values containing \\ would never get split. Avoiding this this edge case regarding backslashes seems like something everyone who uses scripts would want, perhaps even purely manual-entry users, so I'm not sure if it makes sense for this feature to be a toggleable one, but rather the new behaviour going forwards. Forgo the automatic splitting, and manually split on demand makes most sense to me, be it via Split fields by separator or quickly using a keyboard shortcut.
Going further, using a keyboard shortcut would have to work in the main view the Tag panel, and Extended tag's Edit tag info popup. Something would also be needed to be done for the main view's and Tag panel's text fields to make it obvious that the value you're looking is a single field value, or multiple field values separated by \\.