Q: Ingest new version with old version archived - Revisited & solved

I couldn't react to the old thread anymore, but I'd like to share the solution with this forum, because it shows the power of the default functionality in the system.

Start situation: asset is archived, new version comes in, overwrite is set to 'on'.
What happens and could happen afterwards: new version 'takes the place' on the hard drive of the old version, new proxies are created, the archive flag on the asset is still on. A restore would place the old version back on the hard drive erasing the new version. No new proxies are created, so original asset would be old version, proxies are from new version. New version - Original Media is lost.

So this is how I solved it:
I created a subscription - event type = modified - in which the Asset Filter is set to:
Archive Status EQUALS Offline
File Modification Date: the Trigger-if-changed box is ticked.
The response is changing the status of the asset to 'New Version'.

A second subsription - event type = modified - has the Asset Filter set to:
Archive Status EQUALS Offline
(Asset) Status EQUALS 'New Version' with Trigger-if-changed box ticked.
The response is:
1. changing the status to 'Completed'
2. duplicating the file to another device, "Archive_Exchange" (no Asset, no Proxy created)
3. restoring the (old) file from the archive.

A third subscription - event type = modified - is subscribing to a job:
The job filter is:
Title CONTAINS 'Restoring'
Owner EQUALS 'admin'
Status EQUALS 'DONE' - Trigger-if-changed box is ticked
plus definition of FROM and TO devices.
The response is:
Scan the device "Archive_Exchange"; the only metadata which is set here is:
Metadata Set equals 'Media' and status equals 'New Version'. No proxies needed.

Subscription #4 - event type = created - is looking for the newly created asset on 'Archive_Exchange'
So filter is: Metadata Set EQUALS Media, Device (Stored On) EQUALS Archive_Exchange and status EQUALS 'New Version'.
The response is this time exactly the same response as when this new version had come in while the old version was not in the archive. So it's copying the new version in the usual device, overwriting the old version and that's it! To keep the temporary device Archive_Exchange clean, there is also a delete response.

It's a little bit 'Working-around-the-bugs', because why is the system copying the new version to another device, while it knows the Original Media is in the archive, but still, it works and the beauty is: no scripts needed!

Thanks for your input; it made me understand processes better so I could create this monster.