From what you write I can see that you are not a developer. That is not a problem at all but then you shouldn't use arguments only developers can make use of.
In fact even in ID3 it is a simple variable/value list. It may use an "optimized" way to store the variables/values but that optimization is not that important nowadays especially it doesn't reduce the file by megabytes at all. It is however useful for streaming audio but then again you don't need a huge amount of metadata here since you don't keep that data, you just listen to it so at minimum ARTIST and TITLE is required. In the streamers library however he may want to have much more metadata but he doesn't have to stream these to the users.
That is exactly what I'm saying but you rejecting.
Instead of hardcoding "TXXX:MusicBrainz Album Artist Id" for MP3, "----:com.apple.iTunes:MusicBrainz Album Artist Id" for MP4, "MusicBrainz/Album Artist Id" for WMA and "MUSICBRAINZ_ALBUMARTISTID" for Vorbis and APE the developer could have saved a huge amount of time by simply using "MUSICBRAINZ_ALBUMARTISTID" for all formats and simply add the corresponding prefix for the given format.
You don't have to check the file format and then write to the correct tag, instead you write directly to $format + MUSICBRAINZ_ALBUMARTISTID.
If it's MP4 $format contains of "----:com.apple.iTunes:", if it's MP3 $format contains "TXXX:" and so on. This way is much easier in terms of developing than how it's currently done. By the way: the same applies not only for tagging software but also for music players! And if you want to support a new format you simply have to change the $format specific prefix (and for sure where to write the tags at) but you don't have to implement the whole format specific tag names again.
You still didn't got the point. My suggestion was and still is not about using a complete different format for Picard only and then let the others apply to it or not. It's about getting in contact with them to 1) agree to work together, 2) publish a survey on each of their websites so that you get data from as much as possible users back, 3) think about how to get the best out of what the users voted and 4) work out a plan to which everybody currently part of the "committee" can stick to about how and when these changes are going to get implemented.
That is wrong for A/C Chargers, Character Encoding and Instant Messaging. Instead of having plenty of chargers I now have two that have the same connector. Instead of plenty of different encodings we have UTF-8. And since Instant Messaging Protocols are proprietary and very often closed-source you have to build your own if you want to offer an Instant Messaging App. Yes, there is Jabber but guess why "nobody" uses it. It has too many flaws and is missing functions and the "main developer" doesn't want to update it.
Well, if you publish a simple "How to use" paper that gives examples they will stick to it, because the better they represent their data the more likely users will buy it. And I've never seen any of such papers issued from ID3, Apple and so on, thus people are looking for their own way.
If you give me links to the sourcecode of each of the software and online services I'll do it within one week. Because it is more or less just changing eg. "TPE2" to "TXXX:ALBUMARTIST" or "TXXX:MusicBrainz Album Artist Id" to "TXXX:MUSICBRAINZ_ALBUMARTISTID".
Think Big. If the majority of tagging and playback software uses the new format and there is just you not using it, guess what happens: You can heck off and kill your product because nearly nobody wants to use it anymore.
Yeah, for sure does this player do some kind of mapping, I never said it does no mapping at all. But instead of using MB data (if present) it rescans the individual songs and tries to match them against GraceNote - which in my eyes turned from awesome to crappy within ~10 years. I guess it happened when Sony bought GraceNote. Dunno.
This is no harmonization but simply mapping. Harmonization means you name as much tags as possible the same while still keeping some kind of backwards compatibility.