I do understand that it's easier to be a nay-sayer than to contribute positively, so I kinda regret doing this.

For non-shared perls, that's great. For shared perls, it merely might be good. There is a lot of thought that needs to go into giving Config.pm the teeth it needs. Some of it is reasonable, some much more difficult.

There are at least a few different uses for Config.pm that I'm aware of, and thought needs to be applied to all uses (whether I've thought of them or not). That doesn't mean that they all need to stay in Config.pm in Perl6, only that these different "users" of Config.pm still can do what they need to. For lack of better terms, they are:

1. The IT guy. This is the guy whose task it is to compile a perl that is usable by one or more machines. This is the person who is creating the initial Config.pm (though s/he may not realise it) to compile perl itself, plus all the modules that come with Perl.
2. The global module installer. This is the guy whose task it is to install more modules over the rest of the use of this copy of perl.
3. The local module installer. This is someone who doesn't have full privileges to the system, and thus is installing some private modules to use with the global perl.
4. The user. Someone who is running perl code, not necessarily caring that the code is in perl.

Except for the first role, each role has a many-to-many relationship to people: more than one person may have sysadmin authority to install global modules, more than one person (possibly on more than one computer) will install local modules, and, hopefully, more than one actual end user, but even then there may be just one end user (and that user could be cron or apache).

At the other end, for example at home, all these roles are filled by me. The configuration must work for all these roles, or as many roles as are solvable and realistic (the user role must always work for all machines sharing the same perl).

That said, this may really work, with a good design. I just think it's a bit more complex than you're implying, and would look forward to some group coming up with a universal solution here.

The first is that you can insist all you want, but when vendors ship binary distributions they won't pay much attention to whether the configuration is accurate, and users won't be first to blame the vendor for those mistakes.

The second is that I've done several network installs of Perl. That's where I install Perl to a file server that a bunch of Windows machines all see, instead of installing to each machine. Yes, I know all of the ways that this is fragile. But it has worked very well in practice, and you'll find that people will do this whether you like it or not.

As for Config ... I actually don't know how much is going to be needed, frankly. Especially given the idea floating around that documentation for a module should be within that module's install. Maybe the manpages for Perl shouldn't be in $Config{man1}, but $Config{perlmanpages} and let the understanding of that be OS-dependent.