avatar subclasses

This message contains a proposal for an approach to easily handle
avatar subclasses.  Your response is requested!

Currently:
-----
When creating a new Croquet world, a new subclass of
CroquetParticipant is also usually created in order to handle the
specific portals in the world. This subclass of CroquetParticipant, or
one of its already existing subclasses, contains the base Morph that
appears in the local user's screen within which the Croquet world gets
displayed.

If a new kind of avatar is desired, it is necessary to subclass
CroquetHarness, or one of its already existing subclasses, in order to
overload its #initialize method to create the desired new subclass of
TAvatarUser. This new subclass of CroquetHarness is created in the
CroquetParticipant subclass #setup method. The #replicaClass method of
the TAvatarUser subclass should also be set to return the paired new
TAvatarReplica subclass, which must also be created.
-----

Proposed:
-----
Because all of these classes required to subclass an avatar are
"user-side" entities, except for the TAvatarReplica class which is
already parameterized by the #replicaClass method, and the fact that
most references to these objects throughout Croquet refer to their
instantiated instances rather than the class names, might it be a good
idea to parameterize the names of ALL of these classes?

Since the new subclass of CroquetParticipant is more or less the root
of this set of classes as far as how they get instantiated, is it be a
usable idea to create methods in the CroquetParticipant class proper
which could be referenced by these classes to create the required
subclass references?  In other words,

CroquetParticipant>>#avatarClass
CroquetParticipant>>#replicaClass
CroquetParticipant>>#harnessClass

Overloading these methods in new CroquetParticipant subclasses would
be trivial and allow wide flexibility.
-----

I have not tried implementing this yet and there may be unforeseen difficulties.

What are your thoughts on this proposal?