Improving user experience for file changed status?

I frequently find that when I reopen a piece to rehearse it, I change something which is cosmetic rather than substantial. For example, changing the 'concert pitch' box, changing from continuous layouts to page layout, adjusting the output of one instrument in the mixer or turning on/off the metronome.

In these cases, the file is marked as modified just as much as when I delete a bar or change the pitch of a note.

This means that it's almost impossible to do anything that doesn't result in a 'Do you want to save the score?' dialog box. Even using UNDO multiple times doesn't result in the file being shown as unmodified when the mixer has been changed. So I always end up saving the file because maybe I also fixed a note or a dynamic (but maybe that was an hour ago, or maybe that was last session, not this one).

Also, it's incredibly easy to type something on the keyboard or move the mouse when something (or the wrong thing) is highlighted resulting in an unintentional change. So - highlight a note and accidentally use the arrow key changing the pitch and then changing the reverb setting a bit both result in the file being modified. You can't undo everything because the reverb setting doesn't undo - so you never really know if your file is substantially different. Or changing the metronome in the playback control doesn't cause the file to be changed, but muting it in the mixer does. And you can't undo it.

As a user I would like to have more control over what counts as modified and some knowledge of what the changes were. I can think of a number of things that might make this a better when I am using MuseScore to rehearse (which is most of the reason I use it).

Some / any of:
1. tag operations with some kind of 'group'. For example:
a) changes to the score (adding notes, changing pitches, deleting bars, adding Swing text) might be level type
b) changes to page format (paginated, continuous horizontal, continuous vertical).
c) changes to mixer volume settings.
d) changes to plugins (reverb, compressor, filters).
e) changes to playback (turning metronome on and off, percentage speed playback etc).
Not necessarily these exact groups but allowing the user some control over what kinds of changes need to be saved. Maybe there only need to be 2 or 3 groups, maybe there are reasons to have more?

The user could alter a preference for which kinds of changes count as 'modified'. Or maybe it could be particular to each file having been originally set in preferences (default to 'everything counts as a change' to start with until the user changes it).

2. A list of the types of operations that have cause the file to be modified. E.g.
   a) once any note pitch has been changed or notes added / deleted etc. Then the 'score changed' flag would be set.
   b) If the page view setting was change then the 'page view changed flag' would be set.
   c) If the mixer settings are changed, the 'mixer settings changed' flag would be set.
   etc.

3. When the 'This file has changed' message is presented to the user, present a simple list of the types of reason the file counts as 'modified'. Maybe even with a few options to allow the filter to only save some types of change.

Normally when rehearsing I don't change the notes but I do change layout, playback speed and mixer settings - in this case, I don't necessarily need to save these changes. I am unlikely to want to save note changes in a file if I think I haven't actually changed any but I can't tell because lots of other things also cause the file to be 'changed'.

I am sure all the different types of user would have reasons why the would or would not want the file to count as 'modified' - this would alleviate the uncertainty caused by whether the file 'changes' are likely to be important enough to change or even intentional.

I have no idea how complicated this might be but I do frequently find myself unsure of whether a file needs saving. The alternative is to use source control for all my MuseScore files (which I could do but it wouldn't be easy to actually see what the changes were - it would rely on users being able to operate Git etc and still wouldn't help with unintentional changes.

And finally, the metadata for the time modified $m - doesn't necessarily change when the file is 'modified' and some things (e.g. metronome volume in the mixer) cause a change in the 'file modified' status and prompts for a file save but doesn't change the metadata. (This may be intentional - maybe the metadata only reflects changes in the printed page? This would be good because I wanted to use the 'modified date' and modified time' to help keep track of whether a printed copy was up to date).

Anyway - just something to consider?