> we need to with clarity raise errors that don't come from system or library calls, such as when we detect that a SRFI 170 procedure is handed an invalid argument.

This separation of syscall errors from wrapper errors is good.

> So John is planning on breaking that out into its own SRFI as he's done with the POSIX timespec SRFI 174.

This is almost certainly a good idea. Not sure what detailed approach is
best, but that's what the SRFI process is for :)

It'd be particularly nice if errors from standard RnRS procedures like
open-input-file would also have their Unix errno/WinAPI error values
accessible.

Bonus points if the exception says which syscall the error came from, so
we can write third-party libraries that provide improved error messages
(like that C library John linked once, whose name escapes me).

> Would it make sense to turn that into a general "systems errors" SRFI, for "arbitrary" errors from alien technology stacks like SRFI 170's POSIX, and myriad databases for us? And have John's Simple SQL, my DBI, etc. use it?

I'd start by asking what callers need to know in some concrete
situations when they get an exception.

- "Is this error from the OS?" is a concrete question. Then you can
check what the errno is and things like that.

- "Is this error from a database?" may be another good one with quite a
clear application domain.

- "Is this error from the system?" sounds more vague. What exactly
counts as "system"?