This is pretty awesome -- I could see it being applied to a range of things other than debugging (and perhaps some holy wars breaking out about what might constitute overuse or misuse of the idea).

Because of its potential, I think the tendancy to give it a name related to debugging would be... well, constraining or inapt somehow -- it might limit people's perception about what it's really doing, and what it's able to do.

Keeping it as "=begin" seems okay (especially if folks follow Mr. Muskrat's idea of always terminating the conditional code with "=end"). Another possibility would be to call it something like "=run_when" -- e.g.:

=run_when ODDBALL_OS_VERSION.
use Local::Module::ForODDOSV;  # nice to have a new way to do this!
=cut
...
while (<BLAH>) {
...
=run_when DEBUGGING
warn "reading BLAH and got: $_"
=cut
...
=run_when TESTING
$expected = "What should happen here";
warn "This isn't working\n" unless ( $expected eq some_test());
=cut
...
=run_when BORED
print "Did you do something different with your hair today?\n";
=cut
[download]

If you feel that C-like pre-processor directives are really second nature to just about everybody who uses Perl, then you could try "=ifdefined" -- this wouldn't be any worse that "=begin", I think, but really, what's in a name? "bless" by any other name would be no less abstract...

I guess the next thing to wonder about is whether folks might opt for having selected chunks of pod content be produced or not via perldoc, depending on what's in the environment. (This might be tricky -- how to flag the end of the =begin block within pod, without flagging the end of pod as well. Or does the use of "=begin" impose the end of pod processing already? I confess to not having studied pod grammar all that closely.)