I understand continuations perfectly. It is exactly the "capturing all of the state relevant to the session" which is problematic. Implicitly grabbing your ap

I understand continuations perfectly. It is exactly the "capturing all of the state relevant to the session" which is problematic. Implicitly grabbing your application's state – including the context of what code is executing, and all in-scope variable bindings, which is the only "state" in a purely functional server such as you surmised earlier – and wrapping it into an opaque blob to pass to a client is exactly what I mean by "hiding state". Failing to identify and define exactly what is the relevant state with which clients should interact is exactly what leads to issues with upgrades, scalability, and security. I'd have no problem with this technique if, instead of an arbitrary call/cc or what-have-you, the developer had to explicitly name the continuation, and specify and name which bits of state are relevant. This definition could then form the basis of a well-defined public-facing interface, for which application tooling could ensure smooth upgrades, for which security properties could be easily demonstrated, and for which more stringent persistence rules than heuristic-based garbage collection could be defined.