>     Hence the generic Scheme framework could be like:
>
> Okay, this makes a lot of sense to me.  So this has nothing to do with
> Scheme errors: it's a way of reflecting errors from arbitrary C APIs
> into the Scheme condition system.

Exactly. Well, the SRFI's API should be able to create Scheme exception
objects that are easy to raise. But the API should probably not raise
them itself; that should be deferred to the user.

> That being so, I think c-error or external-error is the best name for it.

I like those names. `external-error` is probably better since the same
framework could probably be used as-is for errors coming from Java or
other FFI languages.

`environment-error` is another possible name (by analogy with
environment variables, etc.) But it's getting quite verbose.

`foreign-error` is another possibility, though perhaps a bit confusing.
The errors do not need to come from the FFI even though that will
probably be the most common source.

>     - 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)
>
> Both of these should be symbols.

LGTM

>     - Error message (in English, or a localized one if English not
>     available)
>     - Localized error message (where available)
>
> Since strerror()'s return is already localized, I think there should be
> just one string slot.  Nobody except a human being should be looking at
> it anyway: the other arguments are meant for computers to dispatch on.

IIRC, WinAPI can handle a situation where multiple localizations of the
same set of error messages are installed. By default, Windows (at least
old versions) installed only one set of messages and they were
localized, which meant that the English messages were not available on
non-English editions of Windows. This was a culture shock to a
programmer expecting (US) English to be the lingua franca of computing.
Not sure what the situation is nowadays.

I suspect GNOME and perhaps KDE will also offer localized errors.
Probably other big software packages as well.

It might be best for each "error message" to actually be an association
list of (language . "message") pairs. Users who don't care about which
locale they get can simply retrieve the first one.

> In addition to these accessors, the API would expose a constructor, a
> constructor-raiser convenience procedure, and a predicate, and would
> become what SRFI 198 is all about.

LGTM

> Do we have consensus now?

I'm happy with what's proposed so far.