Added Alex Shinn to solicit an opinion from the developer of the Scheme
version I'm using.  Which is also the R7RS reference version, the
resolution of this issue could compel him to support it if these POSIX
SRFIs are added to R7RS-large (I volunteer to help, but I'll need some
help to further understand Chibi Scheme's internals).

From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de>
Date: Friday, June 26, 2020 1:02 AM

> Am Fr., 26. Juni 2020 um 04:39 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> The Scheme runtime system may change the errno value outside of
> user-controlled code, so the errno of SRFI 199 cannot map directly to
> the errno of the C library.
>
> For example, the Scheme system may call a number of C procedures
> setting errno while compiling code dynamically or run a GC. And both
> can happen, in principle, happen between `set-errno!' and `errno'.

And the step in-between of calling a POSIX function that only signals
an error by setting errno, like getpwnam and getpwuid and their group
versions.  This is the severe danger, compared to calling a POSIX
function, getting an error return, and then checking errno and getting
a heisenbug value.

This can be nasty in general, Chibi Scheme's fancy REPL package sets
errno to 0 before returning from print.

> Thus, as currently written, the specification doesn't help too much.
> SRFI 199's errno has to be abstracted

Would not such a facility also have to be used by all the POSIX
calls that are used in concert with SRFI 199 (and 198, for raising
syscall-errors)?  This could certainly be the Worse Is Better, New
Jersey Style method to solving this very real problem.  What would
this look like?

> (or SRFI 199 has to require that the runtime system of supporting
> implementations has to be rewritten in such a way that any change to
> errno is not visible to user code).

Putting the onus on the Scheme implementation developer sounds like
The Right Thing approach, but I have no idea how onerous this would be
for the various implementations that might be inclined to formally
implement production quality POSIX SRFIs like 170, the terminal ones
including a Terminal User Interface (TUI), the process one, etc.

Too much, and they'll be either not so production quality, or the
SRFIs will be ignored.

- Harold