In the recursive sense, not the "safe for concurrency" sense.

I want to use readevalloop to process command-line arguments, and my
initial attempts failed to handle '"(load "loadup.el") (princ
"Done")'.  So I took a stab at making all the entry points synchronize
with an explicit stack of continuation frames shared between read0 and
readevalloop.

The attached diff is against master from a couple of days ago.  For
me, a configure/build (from scratch) completes *almost* everything
(including the standard AOT native-compiled bits) - it chokes on
lisp/leim/ja-dic.el due to a failure in a compiled function in
bytecomp.elc.  There are clearly still some issues where the new code
is not dealing with unibyte/multibyte correctly.  For example, running
emacs -Q shows the initial scratch buffer contents as:

;; This buffer is for text that is not saved, and for Lisp evaluation.
;; To create a file, visit it with ‘C-x C-f’ and enter text in its buffer.

This is definitely not ready for committing, but I'm hoping someone
else finds this of interest and maybe can spot where I'm going wrong
with the unibyte/multibyte handling.  Or what is going on with
ja-dic.el.  The error I'm seeing there is in the execution of some
byte-code, where some bit-wise operator gets a non-numeric argument.
My only idea at present is to diff the byte-compiled libraries and see
what's going on there - theoretically, there shouldn't be any change
in the results of the byte-compiler.

Thanks,
Lynn