Personally, I think the entire premise of what you are trying to do, and the way you are going about trying to do it is completely wrong.

One of your stated aims is avoiding the installation of perl on every workstation. But, by packaging your apps in this way and running them from a remote share, you are effectively causing Perl to be shipped across the network and installed locally, before the app can start to run. And that process has to be repeated each time each person runs an app. Even when they are re-running the same app a few seconds later.

Also, you complain that one of the packagers doesn't follow use lib ... directives. But lib is a hack. A useful hack intended to bypass silly administrative decisions, but still a hack. If you are responsible for writing and deploying apps company wide, you should certainly have the authorities and permissions to install packages into the production Perl environment. And if all your packages were correctly installed, you wouldn't have to rely upon lib, and the packagers wouldn't be having this problem.

But finally, if you are going to deploy the apps by placing them on a network share, why bother packaging them in the first place. It makes no sense.

If instead, you shared your production Perl installation, with all the packages required by all your apps correctly installed. And place the top-level .pl scripts (or some placeholder .cmd files if some local setup is required), within that installation. Then your users can run those applications from that shared installation. They will load faster because there is no need to transmit, unpack and install everything into the local file system every time.

It makes it easier to test, easier to deploy, easier to control access (via permissions, groups etc.), and you avoid the packaging requirement completely.