That's not it
I am talking about creating and / or deleting and / or renaming of entries, each stored as as separate .MTE file; each file bearing the name of the entry
And that is probably the core of the problem. As each entry is a file then deleting of entry means a file is deleted- and so Mp3tag cannot cancel the deletion of entry as it is has deleted a file and has no "source" to retrieve data from. So in order to provide us with fully working CANCEL button, Mp3tag would have to create some temporary "export" folder, work with files in it and delete the old / original "export" folder only when OK is pressed. And if CANCEL would be pressed then Mp3tag would just delete the new / temporary "export" folder with which it was working and leave the user with the untouched original "export" folder. [Or alternatively Mp3tag could just read all .MTE, and create their name list and copy all of their content to some temporary file or RAM. And I am only just guessing here, giving out theoretical ways to cope with that- I am not a programmer]
The same problem is with actions- as they are stored separately as .MTA files in "data\actions", tempering with them equals currently with tempering with the files themselves
And that is totally no good of approach. I understand the convenience of storage of them in such way; the ability to manipulate them directly from a file level [giving this way ability to copy / manipulate them in a way the software itself does not allow for]. But imagine if in any other software you go to some window with some specific options, look at them, change them a little- but ultimately decide, you do not need any of those changes [or want to make a copy of settings first before potentially messing things up]. But you find out, that the changes have been already made and accepted, disregarding your order of CANCEL- would that not make you angry or at least astounded?