> Following this argument, wouldn't it be enough for SRFI 170 to define
> the following procedures:
>
> (posix-error? obj) -> boolean
> (posix-error-errno posix-error) -> symbol
> (posix-error-message posix-error) -> string
> (posix-error errno message) -> exception
>
> With these procedures, SRFI 170 would be independent of SRFI 198 and
> could be finalized independently.
>
> SRFI 198 can later implement these four procedures in terms of its
> foreign error objects and specify some mapping that has to be obeyed
> for systems supporting SRFI 170 and SRFI 198.

Indeed, I think that would be enough. In fact, not even the raise
procedure `posix-error` needs to be exported since each SRFI 170
implementation can internally raise errors whichever way it finds best.

The API:

- posix-error? obj
- posix-error-errno e
- posix-error-message e

Would be roughly equivalent to:

- (and (foreign-status? obj) (not (not (foreign-status-ref obj 'errno))))

- (foreign-status-ref e 'errno)

- (foreign-status-ref e 'message)

The above definition of the predicate shows why a free-wheeling approach
in SRFI 198 is useful: when you think about it, a POSIX error is quite a
nebulous concept, and not everything usefully characterized as a POSIX
error will come from SRFI 170.

If we're using SRFI 198 to represent SRFI 170 errors, it might be
simplest to put a '(srfi-170? #t) property in there. It doesn't do much
harm to have an extra property, and that name is definitely unambiguous.