FWIW, one of the primary complaints of heard about Elm is that there are no escape hatches, so if it doesn't support your use case you just straight up can't use it. I've seen several reports of people avoiding it for future projects on that basis.
In contrasts, TypeScripts success seems to be in no small part due to the fact that it's trivial to drop down to the full flexibility of JavaScript as and when needed, and that it has the full JS ecosystem available to it.
> one of the primary complaints of heard about Elm is that there are no escape hatches, so if it doesn't support your use case you just straight up can't use it.
Elm has JavaScript interop.
Here's the section of the guide that covers how to use it:
It technically has it, but I think it's fair to say it's very unergonomic and only useful for dire needs
Calling out to JS modules is still a bit of an open question. I'm actually leaning towards not allowing that (there's an escape-hatch for the internal library, but I was thinking about keeping that internal), because as you say it can throw a wrench into the guarantees made by the semantics. On the other hand, Rust has unsafe { } and its assurances remain useful even though they can technically be broken. So we'll see.
I think a much more tractable goal is allowing third-party JS to import and call Bagel code (vs the other way around). That way Bagel can still make its guarantees for its own section of the universe. Though I guess that could still open you up to problems if you, say, passed an impure lambda to a pure function which then called it.
Anyway right now I'm still waffling on these particular questions, though I also have so much more work left to do that I won't be forced to make a decision on this for quite some time :)