BEGIN eval require or similar constructs are a solution, but IMHO that gets in the way of laziness. On the other hand, every good module should have at least a minimum of POD, and the metadata, conceptually, is nothing other than documentation. So it'd be only natural to store it in the POD, which I'm going to write anyways. After some thinking, it seems to me the format could be very simple - rather than cooking up some special syntax, just use the key => value, list you intended for Module::Metadata's import to expect. It would effectively be a section of POD-commented-out Perl code - something like this:

=begin metadata

    author  => 'BRENTDAX',
    version => 0.01,
    license => 'perl',
    threads => 'none',
    thrsafe => 'unknown',
    depends => {
        perl => 5.005
    },

=end metadata
[download]

Note how this also eliminates the source filtering headaches since a POD parser can unambiguously extract the section, unlike any manual attempts to find the semicolon which terminates a use statement. The data found could be revaled just as per the example in your other post. A metadata-aware POD browser could effortlessly present this information along with the documentation, too.

Makeshifts last the longest.