Ah, right.

for my $nm ( qw( io fm cv hv pvlv gv av bm pvmg pvnv pviv rv nv iv pv 
+sv ) ) {
    my $nm_pkg = "B::$nm";
    *{ $nm } = sub {
        local *__ANON__ = $nm;
        my $op = shift @_;
        return blessed( $op ) and $op->isa( $nm_pkg );
    }
}
[download]

As for the POD, think about it: the POD processor is just reading the file. How would it know where to look for what gets seen by the perl compiler at one stage or other when the file is compiled? (Short of solving the halting problem, anyway…) It would have to invoke the compiler on the file and then somehow hook into eval, which isn’t trivial, since CORE::eval has a variable prototype, and it certainly wouldn’t be very safe. So to cover such cases there would have to be some form of templating built into POD itself. And while it might be worthwhile to think about that, that won’t solve your problem.

Makeshifts last the longest.

This is a runtime cost at best, the information can't be viewed statically and I think there was at least some griping that this uncovers a bug in some parts of the debugger (since fixed in 5.9 and maybe 5.8.8). I'll stick to my eval, thank you. That works as well as can be had in perl5 without macros or tt.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

It's not really a bug in the debugger, just a stupid backwards compatibility problem that you can set $^P to avoid.

the information can’t be viewed statically

Err, agreed. So how would do view the eval’ed code statically?

Makeshifts last the longest.