No, it's entirely possible. And that's why we don't think about "has an allocator" as a colouring problem.
Likewise if JavaScript had an easy way to get a handle to its Runtime, and a function "block on promise" in its early days, we'd have never had all these "colouring" arguments.
If javascript worked differently we wouldn't have arguments about that significant feature of javascript.
How would you add "block on promise"? Javascript started off without the ability to block on anything, not even I/O because it didn't have I/O. Later when XMLHttpRequeest was added it was purely callback-based.
There are ways to make that API work but introducing the concept of blocking would be a big language change. It's not fixing a flaw, it's trading away some complications for a different pile of complications. There's still a conflict to resolve in language design when you want some functions that are synchronous and don't block and other functions that are asynchronous.
Edit: I guess javascript blocks on alert() but that doesn't seem like what you'd want "block on promise" to do...
JavaScript is (notionally) "single threaded", you can block with just a busy loop; that's not a language change. It's bad design to block, which I expect is what you mean, but that's not a language problem.
If you did so in a Worker, you'd have your "don't block the UI thread" in there too.
If you busy loop waiting for something in javascript, your program dies. They're not just a bad idea, they're a non-option.
Blocking in the sense of blocking I/O or blocking on a system call is not possible in javascript. So again I ask what you have in mind for a "block on promise" call. The ideas that come to my mind all require significant redesigns of the execution model, or copping out by making every function async and treating it like an await.
In particular with workers in mind, I'll put it this way: If you don't allow "block on promise" in the main thread, you generally avoid these issues, but you also don't solve the problem, you still have async versus not async causing many headaches. If you do allow it on the main thread, how do you keep your page functioning? I can imagine resolutions but they all have severe compromises.
Every time you call a JS function, it's blocking; if it internally busy-looped, you'll die just as much as if you do the loop yourself.
Being able to block on an async function call is just as much of a risk; if it returns quick, you live, if it returns slow, you die.
The solution to "main page unresponsive, terminate page?" is to always return promptly to the Runtime, so e.g. make everything async. But JavaScript is a language, and it doesn't just exist on web page main threads. As much as JS's proliferation everywhere else isn't my cup of tea, a blocking call in a JS cli tool is what you want.
EDIT: I guess to be explicit:
> So again I ask what you have in mind for a "block on promise" call
I expect it to have the same guarantees and risks of calling a non-async JS function.
> Every time you call a JS function, it's blocking; if it internally busy-looped, you'll die just as much as if you do the loop yourself.
But in a very temporary way. If it takes seconds that's a bug, while if blocking I/O takes seconds that's normal behavior.
And I've never seen a javascript busy loop in non-malicious code.
> I expect it to have the same guarantees and risks of calling a non-async JS function.
The main guarantee is that the function will be done and have all its temporary data cleaned up before your (non-worker) execution switches to other code. And in practice you can expect it to return within .1 seconds.
That guarantee is going to be an issue if you try to introduce some kind of "block on promise". And the timing expectation is meaningful too.
