This took me a while to understand your logic as to why this benefits from flowing through, rather than the other way around. It seems strange to me that you would expect to be able to use the id produced later - if you just rearrange them, then it works with flow-around, and that's the order I'd expect them to be in.

But it seems like flow-through allows making it order-independent with a bit more care, at the cost of risking a catastrophic failure if somebody trashes your state, while flow-around insulates you from the risk (it's defensive programming by default, essentially), but then adds risk from structuring your middlewares incorrectly.

That particular case is an obvious ordering problem, but when different systems are owned by different teams it's common to encounter scenarios like that where a team doesn't realize the specific implementation details of something means the data is not available where they expect it to be. With flow-through, anything that is logically after should reasonably expect to receive the context from something which came before it, whereas with around flow you have to deeply understand the full structure of the application to know exactly where context will reach, and refactors become problematic because if things get raised to different levels suddenly they have different contexts.

As for risk of state being trashed, I don't see how that's possible unless you go around sharing stores with untrusted users, in which case it's kind of your own fault if it gets trashed. Generally a store should be owned and managed by the same code so you always fully know what's in the store. Even with around flow you can still get trashed stores if you give others access to the store as they can just store.run(...) anywhere.

The existence of global snapshotting means that (with flow-through) a subtask you call can trash your continuation context. Flow-around insulates you from this because it guarantees that no subtask can affect your state, but at the cost of making it more expensive to extract state you actually want to get out of a subtask. Again, it's a question of intention, assumptions, and defaults.

If we get the defaults right, then it may be perfectly reasonable to say "just don't use global snapshot" because the defaults will make it so that nobody ever really needs to. If we get it even slightly wrong, we risk a cargo cult developing where less-informed developers think they need to use it everywhere and now you're stuck being ridiculously defensive about protecting your own context.

Suppose you have some abstract code like so:

const p = doSomethingAsync();
doStuffWhileWaiting();
await p;

The question of flow-around vs flow-through seems to be entirely about whether doSomethingAsync or doStuffWhileWaiting is more important to retain after the merge. You're worried that flow-around is pruning off the former, but what I'm not fully understanding is why the latter is less concerning to prune off? I get that await doSomethingAsync() is a common pattern where doStuffWhileWaiting is empty, and in that case the only concern is whether or not the longer (more interesting) path might trash something. But more generally, there's a split and a merge and we need to either pick the right context to resume after the merge, or else find some way to cast that choice such that the default is less relevant.