> What about thinking of SRFI 170 as the low-level bare-metal interface
> mimicking C/POSIX as much as possible? On top of that, a more
> Schemely-SRFI could be layered, in which the current working directory
> is a parameter object. I agree that the per-thread semantics are more
> sound.

I would tentatively advise against this since there would seem to be
very little difference between those low-level and high-level APIs.

The low level is:

- Convert Scheme strings and fixnums to C strings and integers
- Make the syscall
- C strings and integers back to Scheme strings and integers
- On error, either return errno as as fixnum or raise exception

High level:

- Same as low level
- Definitely raise exception on errno
- Definitely translate per-thread umasks and pathnames
- Not that many other differences?

So they sound almost the same.

The GNOME API stack is a cautionary example of layering too-similar APIs
on top of each other. The GDK API is basically XLib with some naming
conventions spuriously changed. GObject is a custom object system, etc.
It's quite confusing to use and it seems done just for the sake of
extremely minor wins in consistency and convenience (everything starts
with "G" or something).

By contrast, OS operations that clearly compose several syscalls are
clearly at a higher level of abstraction and could benefit from being in
a separate SRFI.