Nima,
I second Dave in his analysis on YOUR CONCRETE SCENARIO. By requiring a further user action to perform the forced log-out, this might not match the intention (semantics) of the overall mechanism. You cannot guarantee that the user will actually perform the needed request (or is in the position to do so: What happens if the the session time-outs just at the moment the reconnect happens?). Or, in the meantime, till the session is invalidated, she will appear as registered user though a third system induced her immediate log-out (in the XOWiki visitor proxy, for instance). The issue of browser-induced concurrency only makes it worse, as Dave pointed out correctly. If there is a mechanism at hand, that allows you to enforce this condition immediately, do so. It seems KISS and semantically correct with respect to the overall scenario. So, it couldn't get any better :)
Generally speaking, this is another flavour of a "continuation metaphor" stored at the server side for the scope of a session. Continuations are only powerful as a concept if you can continue on a frozen state, just providing for an eval of a proc does not deliver what couldn't be achieved otherwise (as the XOWiki workflow engine does, for instance). The main issue I see is the binding of the continuation life-time to the auth-session life-time. As a general mechanism, one would have to provide for different binding sites ...
