>I love emacs to death, but the singlethreadedness is such a pain. Especially if . . . or just a blocking external process (when you're trying to run two or three or more).
I am having trouble imagining how you end up in a situation where Emacs is waiting on a blocking external process while trying to run other external processes.
There two kinds of external processes inferior to Emacs: those that communicate with Emacs synchronously and those that communicate asynchronously.
The inferior shell process in a shell-mode buffer is probably the most familiar example of the latter. (Any mode derived from comint mode is an example.) Your Emacs is never waiting for an asynchronously-communicating external process, is it?
The prototypical example of a process that communicates with Emacs synchronously is when Dired forks and execs the ls command to get a directory listing. I never find myself waiting for this ls command. The only external process I notice myself ever waiting for is the movemail program distributed with Emacs -- and that never took more than around 10 seconds (and usually a lot less) even on early-1990-vintage computers like a 386. So I am having trouble imagining what your "when you're trying to run two or three or more [external processes]" refers to.
Parenthetically, I could eliminate the delays caused by movemail by rewriting vm-get-new-mail to use async io when it is finished like M-x man uses. Adding threads to Emacs would not be necessary.
But then I have very little experience of or knowledge Windows. Is this waiting you refer to a Windows-only thing?
The OP maintains that it is probably a good thing that Emacs is not multi-threaded, and after 20 years of using Emacs and hacking on Emacs I tend to agree -- but my experience is almost all on Unix-like systems.