Your naming advice makes perfect sense to me. However, after more consideration of the implementation goals I had proposed, I'm now wondering if I should be a bit less ambitious and settle for something that will probably be just as useful anyway. I believe my original plan to deterministically identify the origin package for imported symbols would be more realistic if I drop the goal of supporting non-Exporter.pm exporters.

You're right about the edge cases -- there are some tough ones. I believe that most of the ones I've thought of are within reach. For instance, one interesting problem is identifying which of all the use()d modules contributes symbol S to package P (or if S just came from P itself). I believe I could create a private, empty package in which a candidate module could be use()d, then check the resulting symbol table of the dummy package for symbols. The resulting set of symbols would represent those exported by the module's import().

However, symbols not found this way might still have come from those modules (e.g. the package in question could require() a module M, then call M::import_deceptively(), which may do what import() conventionally does)! The probability of false negatives would be very low, but I can't think of a general way to positively conclude that a symbol has not been imported.

I have a new appreciation for Exporter.pm, much maligned as it has been at times. As it is standard for Perl, placing dependence on it as a precondition for my module's efficacy seems reasonable.

Here are the updated goals for Devel::WrapImportedSubs:

• Wrap subs that use()d modules have exported via Exporter.pm (by looking for @EXPORT and @EXPORT_OK in their symbol tables)
• Optionally wrap subs defined by the caller and fully-qualified subs called from other namespaces (since it would seem that users (like me) who need to do tracing would expect and need this easy-to-add feature)

I'll think about alternatives to Hook::LexWrap.

Thanks for help with advice on the design!