That's a better idea in the case where the inner classes represent things in the user's problem domain that can have different concrete classes. For example, different database back-ends, different template output renderers, and so on.

In the case I'm thinking about, those are not in the user's space. The "real" program I'm experimenting on does conversion of Wiki Creole to xhtml. The heavy-lifting classes inside would seem logical if explained, and concern parsing and processing details. But the user doesn't care, typically.

The user does care about "extensions", such as "auto-generate table of contents", or one to provide for an Anchor/Reference syntax, or perhaps to add totally new grammar constructs that generate whatever xhtml, added into the mix.

The user should simply say "I want the Creole class with this that and the other stuff added in". Using the AutoTOC extension shouldn't come with instructions to tell the user, "after you use this Role, on the resulting object be sure to construct it with c1 and c2 parameters that also have the corresponding roles added to them too".

Using the M role on C should, by itself, also ensure that the M::C2 role is applied to the C2 and the M::C3 role is applied to C3, when the class constructs them.

(Another thing I didn't mention earlier: the extensions should be singular and idempotent. AutoTOC itself pulls in Anchor, and it shouldn't matter if you specify Anchor yourself too.)