The point, as exhibited by the practical issues around Scheme’s call/cc, is that it can be very hard to make different libraries work together when each of them

The point, as exhibited by the practical issues around Scheme’s call/cc, is that it can be very hard to make different libraries work together when each of them makes use of such control-flow primitives. It definitely doesn’t happen by default—if you just use them at the same time, the result will run, but it won’t make sense (or obey the individual libraries’ invariants). 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.