this seems to be very nice but a couple questions came to mind as I read this
1. in the case of a delayed replication (2 hour delay) that you want to restore to match the real one as of 45 min ago, why would it take 1 hour and 45 min to get there ? why couldn't you identify how far you need to go and then process the updates as fast as possible to get to that point in time?
2. could something similar to the script delayed update be used for the traveling salesman problem?
create an additional 'slave' that accepts updates and delayes them indefinantly until the intermittent client connects, downloads all the pending updates, and processes them.