Two other things of note in that example:

- Since CL-style keyword arguments are just glorified plists, we can
leverage CL's built-in keyword argument checking to check the plists
given to `make-foreign-status`. &allow-other-keys is the magic word.
Schemes like Gauche that have an equivalent to &allow-other-keys can
also use that.

For this reason, I think we should specify in the SRFI that keyword
objects passed `{make,raise}-foreign-status` are treated the same as
symbols.

- The errno-status subtype uses the standard OOP technique of virtual
methods (in CL, generic functions) to fetch the message. We don't need
to store a message string in the error object since we can always get it
from C's strerror() function if we need it. I think we shouldn't spend
the time to fetch error messages unless asked by `foreign-status-ref`,
unless the message cannot be fetched later for some reason. Most
messages can be reconstructed perfectly later, so there's no problem.

The CL subtyping and multi-methods system is used to keep the
abstraction seamless for the user so they don't need to care that the
value of 'message is fetched later than other properties. We can easily
do the same in Scheme with transparent lambdas. That's why I'd like to
have them.

This illustrates what a world of difference it makes to have an abstract
data type vs a concrete one. With a little restraint, the interface
becomes simpler for users, and portability and extensibility
possibilities become boundless.