> Oops, I knew I'd make that mistake sooner or later
> https://en.wikipedia.org/wiki/Lassie).

No problem :)

>> Since SRFI 198 is very Unix-specific, we should perhaps submit a new
>> SRFI about the generic framework.
>
> I agree, 198 has unique APIs like errno-string (which you propose to
> enhance, although that's not 198 API visible), and errno-name, which
> gives you the define name, e.g. ENOENT.
>
>> However, it might be a good idea to take the Windows API (and perhaps
>> other OS error APIs) into account in 198.
>
> Is there any 198 API difference that will be visible besides
> errno-name?

I'd wager most mature C error APIs conform to this general format:

#define MY_ERROR_CODE_FOO 1234
...
const char *my_strerror(int my_error_code);

Hence the generic Scheme framework could be like:

- Name of C API that caused the error (as a symbol or string)
- Name of C constant for the error code (as a symbol or string)
- Integer C constant for the error code (as a fixnum)
- Which error collection this error came from (as a symbol)
- Error message (in English, or a localized one if English not available)
- Localized error message (where available)

The error collections could be, by convention:

- errno or unix (the name "posix" would be misleading)
- winapi or windows or win32
- winsock (Windows Sockets errors are different from general WinAPI ones)
- sqlite (https://sqlite.org/c3ref/errcode.html)
- ...

> Which on Windows could just return an empty string, or
> maybe something concise that's Windows meaningful?

The `errno-name` in SRFI 198 returns the C identifier as a Scheme
symbol. WinAPI (and SQLite, etc.) errors also have such C identifiers.
It might be enough for SRFI 170 to simply use the generic error
framework as-is and give errno/unix as the error collection from which
its errors come.