Your way of looking at the facts is not correct.
There is no automatism, because Mp3tag does nothing without user command to do so.
In general, if you give an application the command to save, then the application will be forced to save all selected objects. This is generally known and accepted functionality.
I can not remember that it should ever have been different in any other software application.
A simple way to check changes within an entire tag might be to create an overall checksum at the first reading, then a comparison of old checksum and new checksum after editing can trigger the decision to keep or not the original datetime stamp of the file.
In the meantime you should change your behaviour, which means not to force saving, giving a file a new date, if nothing has been changed within this file.
Maybe 'Save' is not the correct word; how about 'Apply' ?
It was a suggestion to make MP3Tag a little more convenient to use.
If I have a 100 MP4 movie files open, and ITUNESMEDIA = then at least one has ITUNESMEDIA <> "Movie"
I could search and look for the wrong one(s), but it's very easy to just select them, make ITUNESMEDIA="Movie" and save
That works, but as you say, it re-saves all 100 which updates the modification time
All I was suggesting was that instead of replacing "Movie" with "Movie" in 99 of the files and then saving 99 files, since MP3Tag knowns the existing tag value, there's no need to update which eliminates the time required to save, and also eliminates marking the 99 files for backup