Sorry, I have to disagree with all these proposals on technical grounds.

>> While in principle 'set is just another key in the plist, I suggest
>> the following two rules:
>>
>> 1) If 'set isn't present in the constructor, an error is signaled.
>
> That's fine; this already happens in raise-foreign-error, and it's easy
> to have make-foreign-status do that.  Only issue I see is that servers
> making foreign status objects will have to be careful if they don't want
> to crash in such situations.

I think it's unwise to have mandatory properties. What's the rationale
for them in general and for this one in particular?

My intuition says we're mandating too many things for programmers who'll
be facing situations we don't know. We should mandate the bare minimum.
The bare minimum is all properties optional with #f defaults.

If a system can return only the error message, that's better than
nothing. Absent properties are the same as #f, so (eq? 'errno
(foreign-status-ref st 'set)) can still be used to test it even if it's
#f. A set of #f means unknown, but other useful information like the
message can still be known.

>> 2) The foreign-status-plist procedure guarantees that 'set is the
>> first key (which means that which set you are using is always the cadr).
>
> That's a very good idea.
>
> We have to decide if we're going to have a foreign-status-plist.
> There's an argument for having both it and foreign-status-keys.

(eq? 'errno (cadr (foreign-status-plist st))) is definitely not a good
idiom. Not only is "cadr" the kind of obfuscation they don't have in
other languages like Python, but implicitly relying on the concrete
structure of the plist is more obfuscation on top.

I feel I've failed to clearly communicate my point about abstraction.
That's probably my fault.

As a separate issue, the concrete representation of a plist doesn't have
standard tools in R6RS or R7RS-small. If we return a list it should be
an alist.

>> Note from previous email, I'm tentatively changing 'set to 'facility.

Let's avoid the name 'facility for any of the core stuff in the SRFI.
That word is commonly used by external logging systems (syslog, VMS,
...). If we want to represent statuses in those systems, we should use
the 'facility property for something that maps closely to those systems'
concept of a facility.