Yes, this would probably be a better and more consistent approach to the whole problem, in my opinion.
Go with A or with B? Why not both, however you please to use them?
However, generic functions in Scheme have many of the same performance issues as the SRFI 225 (first draft) registration system. Since the only portable typing mechanism we have are predicates, not type descriptors, the only easy way for many implementations to do typing dispatch is calling each predicate in turn.
Fast-generics allows you to specify predicate subsumptions, which is isomorphic to subtype relationships. If the predicate P1 subsumes P2, then the type of objects satisfying P2 is a subtype of the type of objects satisfying P1. So when doing fast-generics on top of a JVM/CLR style type tree, we extend the subsumption relation to know about its subtypes, and then we can cleverly make use of its built-in dispatching.
John has given a very sensible reason why he wants to get dictionaries standardized before the next ballot for R7RS: he doesn’t want more SRFIs and more R7RS libraries defining procedures that only work on one key-value mapping type (be it alist or hash or whatever). However, if generic functions would be a better way of solving this in general, perhaps ‘some timescale’ should considered ‘as soon as possible’. This doesn’t mean work on SRFI 225 has to stop, of course — but we could have two options on the ballot.
Well, if someone turns fast generics into a SRFI implementation (writing the SRFI text will be easy) along the lines I've sketched, we can get them on the next ballot or two -- but there is no reason for them to be mutually exclusive.