Wow, that's a lot of useful and detailed information 
Thanks @LiberalArtist !
To the extent you need them,
ffi/unsafe/vmis probably the best way to get these. You could also consider theunix-signalspackage.
The ffi/unsafe/vm package is exactly what I needed. Since that gives access to Chez's Scheme (register-signal-handler) and ($primitive ...) probably I won't need the unix-signals package.
However, with respect to blocking C functions, note that Racket’s IO functions are non-blocking at the level of the OS process (though some block at the level of the green Racket thread). You might want to use Racket’s process control functionality instead of going through C. In particular, some variants can handle bridging the Racket-thread-specific current-directory parameter and wiring up arbitrary Racket ports to stdin/out/err.
It did not come to my mind that that Racket's IO functions are non-blocking, but it's obvious in retrospect since it has green threads. I will have to use them instead of blocking C functions, and hope they do not cause too much havoc with (dynamic-wind) - see below.
The known issue with Chez Scheme's (dynamic-wind) not cooperating with Racket green threads is important, as schemesh internally uses (dynamic-wind) quite a lot.
I know Rash was built on top of Racket's process control package, and I will need to verify if that package is needed - and if it's sufficient - when loading schemesh inside Racket.
Also, the tip for fixing (import) when using ffi/unsafe/vm is essential too.
I think it would probably work out better to write a compatibility layer in Racket that would let most of your code be shared between both implementations.
Yes, definitely.
Racket’s reader is highly extensible: you can add dispatch and delimiter macros to the readtable to cover #!shell, {, }, and everything else. Extending the Racket reader can also help you cooperate with syntax coloring and REPL support that works with both DrRacket and Racket’s command-line expeditor (and maybe racket-mode in Emacs, and/or other editors via the LSP?).
For the syntax parsing, I do not yet know enough of Racket's internals and how to customize them in order to understand the best way to proceed. The extensible readtable you point out looks promising, and seems similar in spirit to Common Lisp's one - which incidentally, I have some experience with.
I will tackle the syntax coloring at a later time, and it's good to know Racket has a mechanism to customize it too.
(interaction-environment) and (eval form environment)
The needed functionality definitely exists, and may be as simple as calling (read-eval-print-loop) after setting up an appropriate namespace and such. If you need finer-grained control, all of the pieces are also provided.
Yes, schemesh will need access to Racket's (eval) or something slightly higher level as the (read-eval-print-loop) you suggest.
The Racket FFI is a layer on top of the Chez Scheme FFI, and vectors, bytevectors (a.k.a. byte strings), and lists are the same in Racket as in Chez Scheme (except IIRC for impersonated vectors, including chaperones), so all of this should work. In particular, a byte string is a Racket cpointer?. This might be an area where ffi/unsafe/vm would be useful
Good to know and in the worst case, now I know how to use Chez Scheme FFI from Racket: just load with ffi/unsafe/vm the Scheme sources that use Chez Scheme FFI.
If my suggestions above work out, the autocompletion in expeditor should do this for you. If you end up needing to reimplement more functionality, all the reflective operations you need exist, e.g.
namespace-mapped-symbols.
We'll see. Can it also autocomplete file and directory names depending on the current syntax and inside quoted strings?
All considered, it seems a somewhat long and sometimes tricky approach - but definitely feasible.
Thanks again!