I think the solution would be addition of staged commits and stage lock. It feels like an embeded version control system. I would argue the Revision logic should be implemented inside a separate module from the runtime.

Today i have a possible reason why run_once and set_state_change_waker should be abandoned. Our task at the start of run_once is to atomically (all in one motion) increment revision and "lock" the stage_lock with the AtomicCell or whatever. However implementation of RunLoop::poll_next is then rather problematic because of two atomic operations of set_state_change_waker and run_once, introducing a race condition. As I see it, adding Waker to this AtomicCell is unavoidable and existence of run_once alongside with set_state_change_waker is "unsafe".

EDIT: Well maybe i was too unapologetic and adding poll_once (Name subject to change) could do the trick.