Am Fr., 23. Juli 2021 um 18:05 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
Close reading https://standards.scheme.org/official/r6rs-lib.pdf page
26, it says:

"(condition-predicate rtd) procedure"

"Rtd must be a record-type descriptor of a subtype of &condition. The
condition-predicate procedure returns a procedure that takes one
argument. This procedure returns #t if its argument is a condition of
the condition type represented by rtd, i.e., if it is either a simple
condition of that record type (or one of its subtypes) or a compound
conditition with such a simple condition as one of its components, and
#f otherwise."

I take this to imply that wherever the standard says condition type &foo
is raised, the implementation can actually raise any compound condition
that has a simple condition of type &foo as a member.

Yes; an implementation is free to add whatever extra information. In fact, it is even encouraged to do so if it helps to describe the erroneous situation better.
 
So implementations that add R6RS support could keep their existing
native exception hierarchy, and make those exceptions use
R6RS-compatible compound condition objects with R6RS-compatible simple
conditions as members. This should solve all interop problems?

As you say... under the condition (no pun intended!) that the native exception objects are compatible with compound conditions.