My impression has been that emacs itself does fine with multiple processes. As seen by the compilation buffer being fine. So, if you setup a sentinel and do the process buffer technique, things can be done. Most people lament the lack of threads, though. More, I think most people do not want to build the necessary stuff for a process buffer to help.

Happy to know where I'm mistaken there. And I've certainly seen places where a blocking call can be annoying. Usually creeps up into a place that was fine at first. Org mode source execution is a good one. For the vast majority of stuff I do in those, I'm fine that it blocks while it gives me the results. Then I'll kick off one block that I should have added the async flag to, but just didn't.

If I start a long running Emacs Lisp function in IELM (the GNU Emacs repl), then GNU Emacs is completely unresponsive.

My Lisp Machine emulator for Symbolics Genera is still responsive for the same code snippet, entered in a Listener window.

Right. I know if you don't do the process buffer code, you can freeze things. And I can fully cede that doing that for elisp is weird. Same idea in a sly buffer, though, is fine.

sly is easier, there the computation is done by a remote Common Lisp. But the danger may be long running output operations, unless they explicitly give up control for other (possibly green) threads.

But in a Lisp application to not be responsive at all is kind of rare. Most Lisp application runtimes will be able to process interrupts and/or switch "green threads" or "native threads".