The Fully Integrated Happy Path

This is an outline of how the proposed modularity would work if it were fully integrated into Yeoman's infrastructure.

• install a generator of your choice (like always, further referred to as the hostgen)
• install external subgens, either core-dev-maintained or contributed (different prefixes)
• the external subgens are now available on the hostgen's namespace

If it's tackled from the yo-cli side, creating the environment would have to be updated to include logic on the proposed subgen-prefixes contrib-subgen-<hostgen_name>-foobar and subgen-<hostgen_name>-foobar.

In it's env-lookup and registration stage, it would register packages that follow these naming conventions under the host generator's namespace ??? env.register('subgen-<hostgen>-foobar', 'hostgen:subgenname') ???. Let's work with an example package:

contrib-subgen-<host_name>-addons
  /generators
    /foobar
    /hameggs

Yeoman's env would be updated to include scanning for the prefixes and map installed packages in the following way:

contrib-subgen - <host_name> -  addons
                  ∨∨∨∨∨∨∨∨
             infer root namespace

Based on the package example, Yo would register the following namespaces

host_name:foobar
host_name:hameggs

• Arguably it may make sense to give developers an option to include the last token (addons) as an intermediary namespace separator, leading to host_name:addons:foobar, etc.

• Checking for compatibility should be possible by declaring the hostgen as a peer dep in the subgen and using semver to resolve compatibility between the versions (allowing for user friendly log messages if (or once) an update breaks compatibility).

• External subgen packages should be resolvable the same way as generator- packages, i.e. being allowed anywhere inside env.findGeneratorsIn().

• A strategy/hierarchy for handling namespace collisions would be necessary, probably allowing users to configure their preferred subgen in case of collisions (e.g. prompted on the UI and stored in a config file).

Research
One thing I'd like to research is whether it is possible by simply using the env api (and thus not even having to touch Yo's internals, e.g. by extending yeoman-generator's base class)
=> would happen on the hostgen-side, but there would have to be a way to catch the "You don't seem to have a generator with the name hostgen:subgen installed" error as an entry point to scan the env for qualifying external subgens.
=> doesn't seem to be possible, as the error is thrown by the env before any generator code gets a hold on it