> +1.  It also makes matters extensible, which having a fixed collection
> of functions does not.

Concurred, extensibility is needed in any case.

> The standard keys, however, should be documented
> in the SRFI with generic explanations.

+1. Also any extra ones beyond those discussed in the SRFI should be
documented in the error-set registry.

>     But they can be
>     discovered simply by triggering an error in a REPL and noting all the
>     keys in foreign-error:code.
>
> I want to register my continuing objection to reflective functions in
> this SRFI, particularly since they may return an unexpectedly large or
> small amount of information.   Rather than having functions that return
> "some of the error-sets / errors / whatever", stick to specific
> handling.  These lists are going to be unstable anyhow.

It's a good question how we should combine printing error objects from
the REPL with lazy-loaded error information. Should the printer
lazy-load anything at all? It could be expensive or fail.

In case you count error-set enumeration as a reflection, Oracle has
about 37 thousand errors!
<https://docs.oracle.com/pls/db92/db92.error_search?prefill=ORA->.

>     Another advantage is that having foreign-error:code fan out into an
>     alist doesn't require us *today* to anticipate every possible way
>     an error can be classified.

The same benefit can be had if we use one flat alist instead of an extra
nested alist for `code`.

> There are indeed systems that group errors into classes.  Historically
> this has been done by having a common prefix to the key.  Consider the
> first digit of an HTTP return message, for example.

True. How would we represent 1xx, 2xx, 3xx, 4xx as classes? FTP and IRC
have a similar numbering scheme if memory serves.