>> I haven't noticed a disagreement about the overall vision, just details.
>
> This would explain our total inability to achieve a consensus.  I'm
> sorry I've not been able to communicate my vision to you.

I don't understand your remark either :)

I thought the vision was to represent POSIX, Windows, SQL, HTTP, and
countless other foreign statuses.

You and John have been saying 'set should be a required property. I
never properly understood why. I take it you want to be confident that
you can ask "does this foreign-status object represent a POSIX error?"
and always get back a useful yes or no answer. That's fair enough.

But I believe the question you really want to ask is "I just called
rename-file; did it give me a file-not-found error?" For that, you
simply need to wrap a `guard` tightly around the `rename-file` and test
for (eq? 'ENOENT (foreign-status-ref err 'errno)). That works fine even
when that errno is synthesized.

I believe the question "did this error come from POSIX?" is nonsensical.
POSIX is not a definite piece of software on a computer. It makes more
sense to ask "did this error come from a SRFI 170 procedure?", "did this
error come from rename-file?", or "if this error were an errno, which
errno would it be?".

The question "did this error come from the C errno variable, and if so,
which value?" may make sense to ask, but is less useful than the above
questions and orthogonal to them.

I also believe it's wise for 170 to mandate (or at least strongly
recommend) its errors to have properties that are not wise to require in
all 198 objects. 170 errors are much easier to understand than the
universe of all potential 198 objects.

> I don't see the linkage here.  What would be exotic enough that it
> can't be represented by all three of the above options? They're all
> lists of one sort or another.

By exotic properties I meant ones related SQL, HTTP, IRC and various
others that are not urgent for SRFI 170.

> an alist and a plist take the same number of cons cells to collect
> their key/value pairs (and I note alists are messier for list values).

Correct.