>> I don't know what reification means precisely,
>
> In this case, I interpret it as meaning that the Error set procedures
> would be working off an internal database the implementation
> constructs that contains *all* possible errors for an error-set, i.e.
> for Oracle (and only the database?), all 1963 errors, including message
> strings.  Which I wouldn't want to burden a microcontroller with....

Agreed. We should permit an error set enumerator to simply return the
empty set if it doesn't have any static strings (and doesn't have any
symbols/numbers either).

>> Enumerating all known errors in a particular collection can be
>> convenient (prior art e.g.
>> <https://docs.python.org/3/library/errno.html>) but it should still be
>> possible to get the error message for errors not known at compile time.
>
> So the Error set procedures would have both?  Or perhaps construct just
> the subset used by the application??
A good illustration is the SQLite error API
(<https://sqlite.org/c3ref/errcode.html>):

const char *sqlite3_errstr(int); gets a generic error message for the
given int error code. The message should be accurate for all situations
that produce the error code but it may be a bit vague.

const char *sqlite3_errmsg(sqlite3*); gets a specific error message
corresponding to the latest error from the given database connection.

The generic messages can be used as a fallback in cases where a specific
message is not available. We should probably adopt this principle
wholesale for the new SRFI 198.

So the static error strings loaded from disk could serve as fallbacks in
case where getting the message at runtime from the foreign API fails.