So, in fairness, I guess this is closed then. I cannot comment on a response to a bug report of… there is no bug if we know and chose to do it “wrong”. Maybe, though, it should be stated that if you save tags in Picard, your files will (or may) contain technical violation(s) and you have no option to stop it as your version setting is not adhered to? If I misspeak in there, it is because I can only speak to my experience, which I fully admit is limited as I am only using Picard for tagging in order to find the issue that was reported. But at that, I can 100% reproduce it, using my same system, settings and type of files used as inputs. So obviously any change in there could cause differences in output, which a more regular Picard user for tagging would likely know better than I.
I want to add that I use, approx 95% of the time, files with original supplies metadata, and I have used MP3s for testing here with the metadata as-is from the distributor. My point is that I am not testing with anything that any other user will use, assuming the distributor is the same. And it is worth noting as MP3 and iTunes are mentioned… iTunes supplies M4A container files, not MP3 files. But, you may be referring to files that iTunes the software has encoded as MP3 files, or maybe MP3 files tagged in the iTunes software. I cannot speak to that as I do not use Apple software, aside from borrowing specific libraries and such to get the AAC encoder portion.
To each their own though, and I agree it is software and hardware that does not follow the standards that cause the problems, Unfortunately for me, the softwares I use and the types of files I use, the solution is to not use Picard’s save button, since Picard turns out to be (for me) one of those softwares that deviates causing issues. I am happy to help test further if there is any interest in fixing anything here, or even if my workflows might help test another aspect. Although I cannot use it, many others do.