WeiDU 200 will not be downgrade happy, ...suggest your fix! Options

[The Bigg]

I've modified the backup system in WeiDU 200, to allow backups of multiple files with the same base name (previously, if you held a backup of E.G. override/baldur.gam and Save/path/baldur.gam, only the former would be restored, resulting in potential problems). Unfortunately, I haven't seen a way to have the system be 100% compatible in case somebody wants to downgrade his WeiDU version (more on the technicalities later). Since I know that some modders on this board insist on using WeiDU 185 and suggesting people to downgrade their versions, I hope to collect ideas on how to fix the situation without stirring excessive trouble.

The only way to cause problems is if user installs a mod using WeiDU >=200 and then uninstalls it using WeiDU < 200. Mixing the versions is always safe during install, and uninstalling a <200 mod using a >=200 mod is safe.

These are the ways to solve the situation I can see:

• I do some further homework and recode this to allow safe mixage. Pro: modders won't have to do a thing, the best of both worlds. Con: I need to think a way to implement this.
  Obviously, this'd be the best idea if I can do this.
• I drop the idea altogether. Pro: modders won't have to do a thing. Con: my personal pride
• I develop a special version of WeiDU 185 that doesn't cause problems. Pro: easy for users, and modders will still be safe from bad ideas. Con: if you have a personal grudge against me, this is not a solution.
• I write a program to make backups 185-compatible. Pro: might be easier to accept for people who dislike me. Con: hard for users.
• Modders not requiring WeiDU 185 for their installs. Pro: users won't have to worry about complicate downgrade routines. Con: if you have a grudge against me, this is obviously not a solution.

Now, the algorithms (PM if you want to read the code), in case you want to brainstorm a better backup algorithm:

WeiDU <200:

{BACKUP}/UNINSTALL.X contains the list of modified files.
When copying override/sw1h01.itm: add "override/sw1h01.itm" to UNINSTALL.X, copy old override/sw1h01.itm (if existing) to {BACKUP}/sw1h01.itm.
When copying temp/sw1h01.itm: add "temp/sw1h01.itm" to UNINSTALL.X, don't keep a backup because {BACKUP}/sw1h01.itm already exists.

When restoring:
read override/sw1h01.itm in UNINSTALL.X, delete override/sw1h01.itm, move {BACKUP}/sw1h01.itm to override.
read temp/sw1h01.itm in UNINSTALL.X, delete temp/sw1h01.itm and do not restore the copy (which wasn't saved).

WeiDU >=200:

{BACKUP}/UNINSTALL_NEW.X contains the list of modified files.
When copying override/sw1h01.itm: add "override/sw1h01.itm" to UNINSTALL_NEW.X, copy old override/sw1h01.itm (if existing) to {BACKUP}/override.sw1h01.itm.
When copying temp/sw1h01.itm: add "temp/sw1h01.itm" to UNINSTALL_NEW.X, copy old temp/sw1h01.itm (if existing) to {BACKUP}/temp.sw1h01.itm.

When restoring:
read override/sw1h01.itm in UNINSTALL_NEW.X, delete override/sw1h01.itm, move {BACKUP}/override.sw1h01.itm to override.
read temp/sw1h01.itm in UNINSTALL_NEW.X, delete temp/sw1h01.itm and move {BACKUP}/temp.sw1h01.itm to temp.

If you can see a way to edit the WeiDU >=200 algorithm so that the WeiDU <200 restoring algorithm still works, this'd be really helpful.