I agree that the prefixed datatypes are a mess and that subtyping would
help. I've been considering putting together an object system SRFI,
likely based on one of the many CLOS-like systems in Scheme. It should
be possible to find some broadly-compatible subset of features out of
the many CLOS-like object systems out there, and with the right
limitations on multiple inheritance it may even be possible to implement
it on top of Kawa's JVM object system too.

These individual datatype SRFIs with prefixed procedures will still be a
necessary first step, though. The interface methods can be based on
them. Once an object system SRFI is approved, a common container
interface SRFI could be imported without having to import them individually.

On 10/8/20 1:23 PM, Per Bothner wrote:
> I accidentally replied the following to just Arthur, but meant to send
> it to a wider audience:
>
>     I've said it before, and I'll said it again: Having all these
> distinct datatypes
>     with distinct APIs and no subtyping is bonkers.
>
>     Nothing against this particular SRFI, which is just another
>     example of a bad approach to design a language.   Common Lisp did
> this
>     much better in 1984.
>
> Arthur agreed that "we should [probably] have a subtyping mechanism",
> and encouraged proposals along these lines.  However, there is no point
> unless these are a significant number of users and implementors who
> feel the same.
>
> This means not just designing an API for defining types and classes,
> but also re-thinking and slimming down SRFI 214 and a dozen collection
> APIs to make use of sub-typing.
>
> I believe there is no point in continuing with r7rs-large on its
> current course
> without sub-typing; I think it is doomed to sink under its own weight.
>
> FWIW, Kawa's define-class/define-simple-class has the necessary
> functionality,
> but the syntax (based on Common Lisp) may not be to everyone's liking,
> and it has more tweaks and features than makes sense for a standard:
> https://www.gnu.org/software/kawa/Defining-new-classes.html
>
> What is needed IMO is a way to define "types" (interfaces)
> with multiple inheritance of methods (with optional default
> implementation),
> and no fields; and concrete "classes" that implement interfaces,
> have fields, and (probably) no inheritance.