Following on from the 2007 efforts to upgrade the TAP modules, and the 2008 implementation of configure_requires, it looks like 2009 will be the year of "MYMETA.yml".
First discussed at last year's QA hackathon, MYMETA.yml unifies the method by which a Makefile.PL or Build.PL communicates back to the parent CPAN client.
The idea is to reuse the format and schema of META.yml (which CPAN client's need to implement anyway) and have the configure script write a "localised" version of META.yml at user-install time which will contain accurate host-specific dependencies, as opposed to META.yml which only contains "advisory" dependencies.
MYMETA.yml should let us achieve two or three different things.
Firstly, it simplifies and normalises the parsing of metadata from the configure script. Currently the CPAN client needs to parse a special (outdated) section of the Makefile when using Makefile.PL, or use a different similarly special method when using Build.PL.
Secondly, it simplifies the work needed to create new CPAN clients. While we current have two CPAN clients, it's not unreasonable to consider the creation of new experimental CPAN clients to run in specialised circumstances.
Thirdly, it will improve our ability to write new and interesting functionality in configuration modules. For example, Module::Install currently is trapped in the dependency model of ExtUtils::MakeMaker, which only supports PREREQ_PM deps (i.e. requires). With MYMETA.yml Module::Install can continue to use ExtUtils::MakeMaker to do the actual building work, but could write MYMETA.yml itself to provide full resolution dependency information up to the CPAN client.
To kick things off from my end, I've added experimental MYMETA.yml support to Module::Install 0.79.
For safety reasons, at the moment it requires that you issue an entirely separate write command to generate it (WriteMyMeta) and won't be written by default.