Thanks for the quick feedback!

> I think the first half of this makes sense, but I don't think the idea
> of reifying all the symbols of a collections, still less all the
> collections.  The Oracle collection has 1963 messages in it, and who
> even knows if Oracle provides a way to navigate through them.  If we
> keep them just names, we are completely free to let them be used by any
> system, whether we have an overview of it or not.

I don't know what reification means precisely, but the idea is not to
limit a particular error collection to a particular set of errors
defined in advance. The set of all error collections should be open to
changes, as should each individual collection in it IMHO.

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.
People who enumerate a collection should do so with the assumption that
the collection may be incomplete.

I'm not 100% sure that having enumeration is a good idea, so I'll gladly
listen to more arguments to the contrary.

> By the same token, I think it's better to keep the localization either
> on the C side or the Scheme side.  If it turns out that the C system
> can't do localized messages, that you use
> <https://github.com/johnwcowan/r7rs-work/blob//master/GettextCowan.md>
> or something like it.  If the string is already localized, then attempts
> to localize it again will not change it anyhow.

It's not just the problem of turning English messages into localized
ones -- we can also have the opposite problem where we can't get the
messages in English.

If a groveler is run at compile time (or on another computer) to get
error messages which are then saved as static strings for run time, then
it's possible to ensure that error messages are available in a
particular locale. For example, we can ensure that we always have US
English messages for Windows, which is not guaranteed if we retrieve
them from WinAPI at runtime.