>>> Thus we have incompatible visions for SRFI 198.

I haven't noticed a disagreement about the overall vision, just details.
I feel we want the same kind of end result but conceptualize the details
differently.

My main concern is that I have a poor track record of predicting the
future, as do most other people. Therefore I'd like to keep the
interface minimal and avoid coupling any two things that don't need to
be coupled:

- If a property can be optional, it should be.
- If a property can be independent of another property, it should be.
- Missing properties should have #f defaults, a time-tested approach.

> Ditto for the collections used as inputs, and output for
> foreign-status-plist/alist/whatever.  Shall we stick with alists, move
> to plists, and for make-foreign-status and raise-foreign-error,
> require one of those two, or just have the key/value pairs be optional
> arguments, e.g. (raise-foreign-error 'set 'generic-c-lib 'subset
> 'libsodium etc.).

I'm confident we'll figure out the interface if we can only figure out
the properties. Thankfully the more exotic properties can be added
later; they don't need to be ready to get the SRFI finalized.

>> and why it is a must for SRFI 170? What is the problem with SRFI 35
>> compound conditions, which equally pack various data into an error
>> object?

I didn't know SRFI 35 existed. How embarrassing!

It's quite a bit more complex, having compound conditions and letting
the user define new condition types. But a SRFI 35 condition type should
definitely be one possible implementation of the SRFI 198 foreign-status
type.

`condition-ref` is just like `foreign-error-ref` and the field system
works just like the 198 property system. However, each SRFI 35 condition
type has a particular fixed set of fields whereas much of the point of
198 is that the set of properties can evolve and be freely chosen from.

Implementing 198 using 35, one of the fields in the condition object
would have to be a plist (or alist or hash-table) to house all the
non-standard properties. Thus, SRFI 35 `condition-ref` is not a drop-in
replacement for 198 `foreign-status-ref`.