Earlier quoted context omitted.
The problem with abstracting control flow has always been the ease of composition within a program. I'm not sure if algebraic effects make that better, although I like the simplest form (exceptions with resume) for error handling. It's kind of like abelian groups and hyper graphs. They generalize many domains very nicely, and are an attractive abstraction. But it turns out they're too abstract for any individual doma…
But that’s the point…? it’s webassembly not JavaScript or Python. You aren’t really expected to write any of this by hand, even if it’s basically what async functions do under the hood when you type await whatever.
So if you’re happy to fence off the generality at the language-implementation level and only ever use one language at a time, there’s no problem. Even if you’re fencing it off at the ABI level it could work, though practical implementations of that are between sparse and nonexistent. But if you’re allowing the user (libraries?) to actually make use of the platform—and anything else feels like a disservice to me—you’ll have to confront the (non-)composability problem.
At the same time, I have to note that algebraic effects were explicitly conceived as a more composable primitive (compared to monad transformers, initially). I can’t see how they’d solve the finally/dynamic-wind problem, for example, but I haven’t looked into them that deep, either, and given their designers are not ignorant of all this, I’m curious to see what they came up with.