@dearchap This is awesome!
IMHO, it's going to make programs that depend on urface/cli lighter and better.

Overall, I am in favor of this direction 🎉 That being said, I haven't worked with nested modules enough to know the trade-offs. I think that given we're in a prerelease phase anyway, I would advocate for each module being in its own repository.

This could also include addressing the awkwardness of namespace collisions so that instead of having to deal with package import aliases, the declared package names could be like altsrcyaml altsrcjson.

This could also include addressing the awkwardness of namespace collisions so that instead of having to deal with package import aliases, the declared package names could be like altsrcyaml altsrcjson.

What kind of collision awkwardness is expected? I find import like altsrcyaml already awkward.

Here's a good example. https://github.com/knadh/koanf

In keeping with koanf example above I have raised a PR in cli

urfave/cli#2009

This allows map value sources to plugin easily without having to do custom lookups. Once that PR is approved the providers here neednt import the root urfave/cli-altsrc and then each provider can plugin to cli directly. How the provider retrieves its information and unmarshals can be left to its implementation