I have only partially been able to follow your discussions and the
development of SRFI 198, so what I am saying is as a bystander (and
maybe a too uniformed one):

Could it be that the problem you want to solve with SRFI 198 isn't yet
clearly determined? Apparently, you want to define a new type of
"error" object, the foreign status object. In the simplest version,
this status object just has one payload with is just an association
list (in the abstract sense).

Let's take a step back. Apparently, you want to solve two things at
least: (1) Having a distinct predicate for foreign status. (2) Having
error objects that carry an extensible list of properties.

I wonder whether it will help to abstract things a bit more. (1) can
be solved independently of (2). Or, spoken differently, for other
kinds of error objects (like file errors or read errors) it also makes
sense to have such an extensible list of properties.

SRFI 198 is not meant to be based on the condition system of the R6RS,
but I think it helps a lot to ponder about how SRFI 198 would be
implemented on that condition system (see
https://www.gnu.org/software/guile/manual/html_node/rnrs-conditions.html,
for example. Or SRFI 35.).

In this system, it makes sense that being a foreign status is
implemented as a simple condition. And the association list could go
its own condition type (as in &irritants). Raising a foreign status
together with the association list would mean to raise a compound
condition. This way, the association list condition could also be used
for other types of conditions like I/O conditions.

The question that has to be answered then is how certain keys will
interact with other condition types. For example, it is conceivable to
have a condition type &errno which should somehow be related to an
errno key in a general association list.

This is very much related to your latest discussion about organizing
the foreign statuses in some kind of hierarchy. As I guess that you
intend SRFI 198 to be naturally implementable on R6RS as well, I am
sure it will be helpful to conceive an implementation on top of its
condition that integrates naturally and that this will help to
understand the actual SRFI 198 better.

Marc