Alteration Request: Make MP3Tag Not Touch Files Unless It Has To

This is a continuation of my thread here: Unwanted File Timestamp Updates

After some investigation, including updating to the latest version of MP3Tag (3.18), I have concluded it has some (from my point of view) unwanted behaviour.

If tags are edited in the tag editor panel, an explict save is required and a warning given if some other action is about to take the focus away without having saved. On the other hand, tags edited in the listing get saved automatically regardless, despite not having Options > Tags > Save tags when using arrow keys/single mouse click selected (what does that do anyway?).

The problem is that if I double-click a listing entry to have it play in the default player, and fumble the clicks, I can easily open a field for editing. If I then fail to use the ESCAPE key to cancel it and click somewhere else, the target file gets touched even though no alteration has been made to its content.

By "touched" I mean the file archive attribute (A) is set, and the timestamp is updated (unless Options > Tags > Preserve file modification time... is selected). The consequence is that it is not then easy to determine which files have been updated and which have just been touched but not actually updated.

Please consider revising the code so that files are only touched if an actual change is made to their data.

Here is a similar idea:

And a reply by the developer to the alleged bug:

I'm not saying it is a bug, and neither is it quite the same situation.

It's reasonable to expect a block of selected files to get updated by a tag update operation, although for management purposes it would be handy if any individual file were only touched if an actual change is made.

At least the tag edit pane has an explicit save. Tags accidentally opened for editing in the file list do not have an explicit save – if you don't want to save (and thereby touch the file) you have to a) notice a tag has been opened for editing (which isn't necessarily obvious, especially if the tag content is just one character), and b) explicitly not save (ie press ESCAPE). Any other operation at all (eg a mouse click) results in the file being touched, and maybe an unwanted tag alteration as well.

This does not seem (to me) a particularly difficult thing to fix.

The interaction with the tag panel is different:
As you can select a lot of files, saving the modification each time you jump to the next object in the tag panel, would slow down the editing process.
And as MP3tag does not know when you have finished editing, you have to explicitly trigger the saving.
In the file list, you can only add one field at a time and only for one file at a time. There it is rather convenient to save as soon as the edit mode is finished.

This is not totally true: you have to click on/in an editable field. A click on a read-only field will not cause any update of the modified date.
But if you click in an editable field, then the assumption becomes true that the user wants to edit - with all the consequences.

Fair enough, I wasn't saying I disagree with that – in fact, I was supporting that.

That is not totally totally true (there is a misunderstanding due to the limitations of posting in text): if a field is opened for editing (possibly accidentally), any click anywhere (even outside the MP3Tag window) writes back the tag.

Convenient maybe, but it is an unsafe assumption that it is what the user wanted.

I also don't understand why the state of the MP3Tag window is not preserved when switching away from the window and returning to it. Why isn't a field being edited held in that state?

Another situation: editing tags down a column using RETURN to open each tag in turn. Press RETURN a second time to skip a row, and that file gets "touched" unnecessarily.

I say again: it should be simple enough and not processor-demanding (in single tag mode) to check whether there is a material change to the data before actually writing it (whether by setting a "modified" flag, or comparing data), with one caveat:

IF the file is being locked from alteration by other apps by opening it for write, AND IF closing the write handle (even without actually writing) automatically sets the Archive attribute (we know it doesn't necessarily update the timestamp, as that can be disabled in settings).

Where's the harm in asking for such a simple thing? Whose use-case would be negatively affected? It's as if design decisions made should be inviolable.