If it uses file path as a track identifier, it won't recognize existing files even with a slight change in auto-organization rule.
you are quite right. thank you that you asked this question early. mb supports for hidden custom tag which can store multiple custom ids for various plugins. this tag is used by ipod driver and google play music plugins. this approach reacquires very many workarounds to make sure that ids are generated for all tracks (ids should be somehow generated on 1st run of plugin, plugin can be temporary disabled, so library should be scanned for empty ids on every start, track moved from inbox to library must be intercepted to generate id, etc.), but file paths as ids are unacceptable.
there is another important question concerning 'tag history': should plugin cache (load to memory) all backups on startup or only information for this track should be loaded on right-clicking on track? its a 'speed vs consumed memory' question. considering that 'tag history' menu item must be disabled if there are no backups for this track, there may be temporary freeze just on right-clicking on track. tags might not to occupy much memory by themselves except for artworks. but what if there are 100's of backups? the problem is that there is a limit on available memory: only 2gb for 32-bit apps. what do you think about this?