in reply to subroutine good practise
In my opinion, when a program is constructed in such a very “dynamic” way (for what purpose? “efficiency?”), it becomes utterly impossible to test it. It becomes, in effect, many different possible programs, depending on (as you say) “how it is called.” This practice is completely unacceptable to me, due to the inherent business risk.
In my experience, most such programs can be, perhaps with some effort, “de-fused” into one or more modules of common-code which can then be used by the specific in-house script that invokes them. These scripts ought not attempt to make any decisions as to what code they do or do not invoke, and they should universally use use to do so. (This is not, of course, an impregnable requirement, but IMHO it is very nearly so. Obvious exceptions such as RPC::Any::Server are also very-limited in what they do and how they do it, and the required modules are also clearly “top-level handlers,” effectively selecting among possible scripts to call; not the case here.)
Any piece of software that is in service needs to be buttressed by independent, automated tests that can demonstrate that, in every case which that piece of software supports, the software works correctly. If what the piece of software is composed of is subject to variation, that becomes pragmatically impossible to do. What a group of scripts have in common, reasonably should be in-common, so that the common pieces can be tested and the tests will cover all of that code’s users. If thereby the program contains code that it does not make use of in the course of any particular invocation ... who cares. Such is of no consequence.