As you say in a later post, there are indeed two issues here, the first being the storage system of the modules, the second the use one makes of the files ones they are out of the CPAN system and stored on your local system.

I don't think it is such a bad solution to use the file-system as its storage system. After all the modules are basically just files and unless you really want to change the whole module system as it is implemented on your local Perl installation, I don't see what is wrong with it. Versioning is one issue (perhaps), but that can be handled within the file-system by adding a version number somewhere in the file-name (or perhaps rather in the parent-folder name) or in a 'version'-file somewhere in your module tree.

And of course one should not forget that once the 'raw' files are transformed into perl-modules by the magic of make they are (and must be) simple folders or files, unless you want to change the whole of the module storage concept in Perl.

By sub-contracting as it were, the storage of the 'raw' files and the 'finished' modules to the local filesystem, Perl solves the storage problem in a very elegant, transparant and simple way, which works on all OS'es (as long as they have a file-system with a directory structure of course) without any need to install some OS-dependant program, driver, ... to do this.

Your solution would call for a database system which must work on all types of OS'es for which there is a Perl-installation and finally you store the results after make in the local filesystem anyhow. I'd say Better the devil you know ...

The second issue you raise (one locally installed generic makefile, optimised for your local Perl during installation of Perl6) would shift the burden of writing 'this works everywhere'-makefiles away from the module-writers to the Perl6-makers. I confess that indeed the hurdle of having to write such a makefile has until now stopped me from contributing to CPAN as I cannot test my modules or the makefile on anything other than WIN32-systems and in any case the makefile syntax looks like deep and black magic to me.

However, I think that such a generic makefile will become the next stumbling stone as it will be difficult to guess what (future) modulewriters might require it to be able to do. The fact that writing a makefile is so difficult is perhaps because it is so powerful (I never really tried my hand at it, so I'm just guessing here) and the syntax is so rich and arcane since it must follow this. And whatever this generic makefile's strength might be, it will still have to get some instructions from the 'raw' module files, so from writing a makefile, we go to writing some sort of a config-file. I'm not so sure that that will be easier.