Just a quick note... Many programming language's OS API effectively
gives you 'errno (a symbol) and 'message (a string).

If SRFI 170 says:

- all errors are raised as SRFI 198 foreign-status objects

- The implementation should work hard to fill in the 'errno and 'message
properties whenever possible. 'errno can freely be synthesized from
other operating system's similar errors, but should not be entirely
fantastical just for the sake of having it present.

...wouldn't that get us everything we urgently need and most languages
give, with minimal effort and minimal restrictions on the final form of
SRFI 198.

If we have a property named 'errno, it makes no sense to put anything
other than C/POSIX/Unix errno compatible values in it. Anything else
would confuse people. Likewise, C/POSIX/Unix errno numbers are not
portable, so clearly the value should always be symbolic (ENOENT etc.)
instead of numeric.

If we have a property named 'message (or 'text), it makes no sense to
put anything other than a human-readable string in there. We can't
guarantee that an English message is available in the general case, so
'message can be whichever localization is at hand. We can later add a
separate 'localize-message or something to deal with that -- it doesn't
have to be SRFI 170's concern.