Stage 2: Now that the transaction order is established, validators can go to work. Each one is responsible for following some contracts, and so is capable of validating transactions up to the point that one of them includes a call to a contract they don’t follow and whose pre-state hasn’t yet been validated. They release affirmations into the network for everything they can validate, and these get formed into a block, subjected to consensus, and committed to a second chain.
This seems fundamentally similar to the approach I described for synchronous cross-shard comms here Simple synchronous cross-shard transaction protocol. Basically, an individual validator aware of the state of some shard A up to slot N and the state root of every other shard up to slot N can incrementally compete the state of shard A up to slot N+1, and then wait for light client confirmations of the state roots of all other shards up to slot N+1.
I think the main reason I haven’t been thinking about this approach at layer 1 is just that the logic would be too complicated (part of the reason I insist on writing these proposals in python is precisely so that we can upper-bound the consensus complexity of actually doing them 
), and it also introduces a high layer of base-level fragility: if any of those light client confirmations for any shard turn out to be wrong, then the computation for every shard from that slot on must be thrown out and redone.
Though I feel like it should be possible to code this up as an EE…