Apologies for the thread hijack, but I didn't want to leave my mistakes above to mislead others - a fine example of a noob getting ahead of himself, greatly appreciate it if one who knows more corrects any further mistakes in my notes-to-myself-while-learning "corrections" below.
I just discovered by looking at my tags with other tools that show the actual tag fieldnames (see the "diffing" thread), that I'd misread the docs, and the Source field is the one that's actually written to the file. This means that for my purposes, I need to go back and reverse at least some of the mappings I posted above. Plus I need to change some that foobar2000 the tool I'm using to convert my FLACs needs to see, e.g. "CONTENT GROUP" with a space rather than not.
Obviously leaving the "shipping default" set:
"DATE" in FLAC for YEAR in ID3v2, and
"ORGANIZATION" and "TRACKNUMBER" are all canonical as per the xiph.org spec
Note that the "Target" string, as a UI alias and in effect can no longer be used as an actual field name in that format. Bottom line - the only reason to mess with mapping AFAICT is when you need to use a Target string in your MP3Tags UI, formulas etc - you then CAN'T use the Source name for that purpose, which remember is the actual physical field for the specified format - that string now becomes irrelevant and unusable.
Therefore for example it doesn't make sense to map "Album Artist" to the canonical internal ALBUMARTIST unless you only want to refer to it with the former string with the space.
And note as well that one of the pair should be the internal name in MP3Tag for the standard mappings (e.g. to ID3) to continue to work.
Question for those who know more than me: In such a case (with hard-coded internally mapped strings) it doesn't seem to be a way to force duplicate fields to be automatically written, the user must manually run Actions?
And a final comment - this is a perfect example of where it would be more user-friendly not less, to allow an option for MP3Tag itself to display the actual fieldnames rather than forcing us to use third-party tools to analyse the results of its behaviour - which BTW is most excellent but you have to get to understand what's happening under the covers.
Not criticising at all mind you, in fact I"ll take the opportunity to once again thank the devs and the supporting community here for all their hard work on this most excellent and useful project.