The exact specification of a SRFI 225 analogue for, say, sequence types is not important for my point. My point is that other typeclass APIs may naturally have more than one per-type predicate. As it is certainly nice if the various typeclass APIs are similar, SRFI 225 should anticipate this. So the "one" you mentioned should not influence the API design.
I realize now that I have been (carelessly) misreading you all along. I thought you were talking about novel type *instances* (of the Dict type class), but in fact you were talking about novel type *classes* in some way analogous to Dict.
My view on this is that (so far at least), every type class should have its own interface that is particular to itself, and that there does not need to be such a thing as a type class creation framework. It may turn out eventually that we can design such a framework that is suited for Scheme, but I don't yet see what it ought to look like, and I think that with only two typeclasses there is not enough evidence for what is suitable.
PS A completely different point: Has anyone yet thought about allowing SRFI 222 compound objects containing a DTD as well as DTDs? This will be extremely helpful for future extensions but it will need an efficient implementation of SRFI 222 accessors.
I don't think that makes sense for instances of *Dict* class; it may make very good sense for other type classes, especially those that come in heterarchical families: Sequence, Functor, Magma.