I think the problem is that you are taking a reference to the %default_values hash, instead of making a copy of it.

The point made by both davidrw and tlm is well taken. I tried it out by rewriting the relevant part of the constructor as follows:

    warn "DV:  " . \%default_values;
    my $self = ref($class) ? bless( +{ %default_values }, ref($class) 
+)
                           : bless( +{ %default_values }, $class );
    warn "self:  " . $self;
[download]

It worked ...

... at first.

Then it didn't.

To keep my original posting to a reasonable length, I only included two test blocks in t/001_load.t. With the suggested revisions to the constructor, both passed.

However, the real-world module of which Woeisme is a distillation included additional test block both before and after the two listed originally. I first added those tests which, in the real-world test suite, occurred before the two cited.

failsafe( [
    'SUBJECT' => 'The quick brown fox jumps over the lazy dog',
], 
    "^NAME is required",
    "Constructor correctly failed due to lack of NAME for module");

failsafe( [
    'NAME' => 'My::B!ad::Module',
], 
    "^Module NAME contains illegal characters",
    "Constructor correctly failed due to illegal characters in module 
+name");

failsafe( [
    'NAME' => "My'BadModule",
], 
    "^Module NAME contains illegal characters",
    "Perl 4-style single-quote path separators no longer supported");
[download]

failsafe( [
    'NAME'     => 'ABC::XYZ',
    'SUBJECT' => '123456789012345678901234567890123456789012345',
], 
    "^SUBJECTs are limited to 44 characters",
    "Constructor correctly failed due to SUBJECT > 44 characters");

failsafe( [
    'NAME'     => 'GHI::DEF',
    'AUTHOR'   => { 
                    NAME   => 'James E Keenan',
                    CPANID => 'ABCDEFGHIJ',
    },
], 
    "^CPAN IDs are 3-9 characters",
    "Constructor correctly failed due to CPANID > 9 characters");
[download]

All tests passed. I added one more test similar to the last one.

failsafe( [
    'NAME'     => 'ABC::XYZ',
    'AUTHOR'   => { 
                    NAME   => 'James E Keenan',
                    CPANID => 'AB',
       },
], 
    "^CPAN IDs are 3-9 characters",
    "Constructor correctly failed due to CPANID < 3 characters");
[download]

All tests still passed. But when I started to add more tests testing values for the other keys of the AUTHOR hash, I started to get exactly the same type of error as I reported yesterday. Adding one test:

failsafe( [
    'NAME'     => 'ABC::Alpha',
    'AUTHOR'   => { 
                    NAME   => 'James E Keenan',
                    EMAIL  => 'jkeenancpan.org',
       },
], 
    "^EMAIL addresses need to have an at sign",

    "Constructor correctly failed; e-mail must have '\@' sign");
[download]

... led to this error:

not ok 22 - Constructor correctly failed; e-mail must have '@' sign

#     Failed test (t\001_load.t at line 88)
#                   'CPAN IDs are 3-9 characters
# EMAIL addresses need to have an at sign
#
# No such file or directory at t\001_load.t line 87
# '
#     doesn't match '(?-xism:^EMAIL addresses need to have an at sign)
+'
[download]

Note that in the last test block, I was not testing the CPANID key; only the NAME key (which should have PASSed) and the EMAIL key (which should have been the sole FAIL). There shouldn't have been any reference at all to the CPANID key.

So it appears we have not yet found the bug! Thanks for those who took the time to look at this. Any other ideas?