Sorry I am just getting back to this now. Spent forever cleaning up some problems in my collection and getting it to work in my library/player (XBMC12 FWIW). Here I think is what the problem is that I had (might not be 100% correct, need to unwind a bit after working like a dog on tagging). The source of my problem is with "album artist" and "genre" but probably has general applicability. In my case most music has multiple album artist and many files have multiple genre. This is a big problem with ID3v2.3, because the spec doesn't really support it, so every app has its own approach to the problem, typically with some sort of "in band" separator (eg, in MP3Tag \\). I found the separator problem insurmountable, but it turns out XBMC will also read APEv2 tags in MP3, and for these (also FLAC Vorbis comments) you avoid separator issues by repeating a field name .
So I used MP3Tag to read all my ID3V2.3 tags and write them out as APEv2, after working to get the MP3Tag \\ separator into the fields. That all worked outstanding, no problems. Note that I have to have unicode support.
My problem came, in that I wanted to back-fill the ID3v2.3 tag frames from the (now correct) APEv2 tags, for use by other apps that can't read APE. MP3Tag was happy to read the APEv2 and write out the ID3v2.3 in the form artist1\\artist2 or genre1\\genre2. But when I read those tags in other apps I was getting duplicates of artist2 and genre2. After hunting through the files, what seems to be happening is that when MP3Tag writes the APEv2 tags, it is in format (0xfeff) . When MP3Tag reads the APEv2 tag and writes the ID3v2.3 tag (in the case where it must concatenate multiple APE tag instances into a single ID3v2.3 frame) , it is in the format \\. It looks fine visually but what I find is that when apps read that ID3v2.3 tag, the second (third etc) occurrence of the is treated as valid data. What makes it more annoying is that I thought I might use a regex to get rid of the but I tried \xFE\xFF and \uFEFF in a couple different regex engines and it never worked for me. The only way to get rid of it that worked for me was to "backspace" across the in a text edit field. You can't see what tags have that "extra" visually, but after a while I could see that if I did a sort some apps would sort out the tags with the . So after a lot of work editing out the s from tags (and also folder names that got corrupted with s) I am now OK, and I now know better than to have MP3Tag write ID3v2.3 tags from APEv2 so I don't expect a repeat. I do think it is a bug, though, as ISTM that the should only be written as the first unicode char in a unicode string.
I agree that ISO 8859-1 was nice, if only we could get the world to agree to use only that char set life would be easy.