This isn't strictly a warnings issue but it may be exception related. Pure compilation errors also will leave %INC populated with the module.

If Foo::Bar loads without compilation errors but its final statement evaluates to 0 in its last line, then $INC{$file} is undefined:

use strict;
use warnings;
0;
[download]

Outputs

=== Eval results ===
result=<undef>
$@=<Monks/Foo/Bar.pm did not return a true value at (eval 1) line 3.
>
=== Contents of %INC ===
$INC{Monks/Foo/Bar.pm}=<undef>
[download]

But if it contains a reason for a compilation error (i.e. no warnings) then $INC{$file} is defined, even if the final line is 0. If, the whole file were in fact being processed and an exception thrown after the fact, I would expect undef as above. If, for example, Foo::Bar contains merely:

{
0;
[download]

the output is

result=<undef>
$@=<Missing right curly or square bracket at Monks/Foo/Bar.pm line 2, 
+at end of line
syntax error at Monks/Foo/Bar.pm line 2, at EOF
Compilation failed in require at (eval 1) line 3.
>
=== Contents of %INC ===
$INC{Monks/Foo/Bar.pm}=<Monks/Foo/Bar.pm>
[download]

I don't know where to look for the source code for "require" without having to download a tarball and grepping my way through it (my google efforts found only the tarballs), but my best guess looking at the pseudocode in require is that some internal implementation of do? is dying when it finds a compilation error. I'm assuming there is some internal implementation because even though do returns undef, a compilation error causes do to set $@ to the compilation error message. Require maybe is calling this internal method but isn't trapping that properly. As a result the code that clears %INC is not being processed. But this is just a guess. Someone with internals knowledge would be better equipped to answer it.

Best, beth

Update: scripts run on Perl 5.8.8