Thanks for the information!

Anyone using caller indirectly, such as through Carp, would be dealing with already compiled code and it would ignore your override.

Given the choice of the slowness of a global override and having someone in the debugger evaluate a Carp and get results that will probably show up in the debugger (since Carp with one level is the most common case), I'll opt for the faster different eval results. If I come accross a specific case where I am annoyed by this, I'll reassess then

Another potential issue is that CORE::caller() has special cased behavior for when called from the DB package. Your code will cause all caller calls to be from the DB package, which means @DB::args will always be populated even when that wasn't the intent. While that doesn't break any obvious things, it is a change in semantics. The effect of this is also currently limited by the previously mentioned compilation issue.

Properly maintaining the semantics of the original function takes extra care. I would recommend looking at Sub::Uplevel. You can likely use it directly to do the frame skipping, fixing both of the above issues. If not, its code can provide guidance on what you need to do.

I don't immediately see how this changes things in my case.

I looked at Sub::Uplevel. The environment and faking going on in my DB code is sufficiently complex that I don't want to introduce more stuff, and other routines adding additional fakery, unless I understand why specifically it is needed. I rely on the tests I have written and when those are insufficient, bug reports and my own experience to tell me if I think things are okay.