Not to repeat myself on this topic, but "you can figure out a way to work around it" is not the same as "this can make your life better".
At no point did I mention anything about workarounds - indeed I proposed at least two things. One we know works exceptionally well in a high-level environment - i.e. non-blocking i/o (whether that be socket/process/file/database or anything of that ilk) with callback (see node.js).
The other is a pattern which is essentially embodied in grand-central-dispatch in macOS and HTML5 workers - i.e. parallel processing / multi-threading is best done by spinning off well-defined 'tasks' which don't interact except at well defined entry / exit points (so you have no chance of dead locks, locking isn't an issue etc.). You get to take advantage of multi-core processors without having to produce excessive boilerplate code to manage the situation and in a way which means you can always easily compose components together whether you've written them or not.
Every time a dialog pops up and stops everything else from happening, you have a use case. That behavior isn't consistent across platforms, which makes it even more of a use case.
That's because wait is recursive and not 'round-robin' (i.e. co-routines-ish). That's nothing to do with multi-threading. Also it depends on what's causing the dialog to appear I guess. Without a direct example / recipe / bug it really isn't a very useful statement.
Every time mergGoogle gets out of sequence and the only way around it is to quit LC, you have a use case. Would you like to know how many times that happened today?
At the end of the day, you've reported this problem numerous times, and Monte has looked into it numerous times. At no point have we had a recipe or anything reproducible. Unfortunately, therefore, we have to assume that is likely a complex interaction in your code that is causing it. I'm sure you appreciate we can't fix things we can't reliably reproduce.
Again, this has nothing to do with, nor would it be solved by multi-threading.
Every time my CRON-wannabe gets stuck because waitDepth>1 when nothing else is happening, you have a use case. That doesn't happen as often, but it happens often enough.
Again that sounds like recursive wait and the problems it can cause if it is not managed correctly.
The biggest culprit of recursive wait is using 'get url' or similar things - i.e. things which block by using 'wait with messages', and then do not prevent triggering other things which also use recursive wait. So the latter wait break condition must finish / complete before the original wait loop can resolve. If you are nesting waits like that, then using callbacks would work better and eliminate the problem. Admittedly, for some operations you have no choice but to make sure you *don't* trigger other things - hey sometimes software APIs have limitations which you have to just deal with. It's not perfect, but then nothing is!
Just to reiterate - all cases of the 'recursive' wait problem can be solved by using callbacks - rather than wait with messages. Or in cases where an API doesn't have a non-blocking (callback based form) you have to just put your app into a 'wait until its done state' and be careful to not trigger any other things which use 'wait with messages'.
It is an entirely separate problem - one which is an exceptionally difficult engineering task to solve - although it is one we will solve in time. It's is why we can't currently support 'wait' in the HTML5 engine, for example, without decimating its performance.
Of course I should have listed the *third* thing we should do is make wait non-recursive (which is essentially the exceptionally difficult engineering task I alluded to above!) - however, please appreciate that that isn't *multi-threading* not in the way you proposed (you mentioned semaphores/locks etc.).
Non-recursive wait is still single-threaded. However it just happens to be an exceptionally good way to deal with concurrent multiple requests without needing the concurrency (which is best server by non-blocking I/O operations, and restricted tasks). Indeed that then get's us something which JavaScript is maybe getting and has been bandied about in node.js for ages - you can write straight line handlers using 'wait' at certain points which do the equivalent of a sequence of handlers, each ending with a 'do this and callback to the next'. (i.e. it is 'with callback' without the boilerplate of the 'with callback').
So - as I said, I'd be interested to head about *interesting* use-cases which actually require multi-threading (in the generality that you seem to be suggesting) which don't fall into one of the categories I listed... All of the above things fall into one of the categories. (Admittedly I missed out 'recursive wait' but that was due to me thinking this was focused on pre-emptive parallelism - and even then non-recursive wait is actually just essentially a syntactic rewrite of 'wait with messages' to be implicitly wait with callback so it was kinda covered anyway if you step back a level).
