Methinx the OP already thought of that - My first step was to move the modules to a local library and to use "use lib ..." to set the path..

It sounds to me like the OP has some legacy code with an incumbent degree of circularity - so I suspect a refactoring may be the order of the day.

I have a hard time imagining a case where a circular dependency would be a problem if the module is installed locally, but would not be a problem if installed system wide.

Except maybe when there are multiple modules installed, and one messes with %INC and @INC at compile time, breaking the circularity by loading a different module - but surely Melasoul would have mentioned such black magic?

There might be other problems though of which I haven't thought at first: If the installation is to work with any version of perl 5, and relies on some modules that are now in core, but weren't at the release of perl-5.0.0, then Melasoul would have to include some modules which are compatible all the way back to perl-5.0.0, but shadow a core module in 5.10.1, and still provide the same functionality.

Frankly that seems next to impossible to me, and opens up the question if the requirements are really as tight as originally described. Or if it might be a better solution to provide a virtual machine with a uniform perl installation than trying to adopt to any possibly perl 5 installation.

Or maybe it's just too late in my timezone, and I'm imagining things... best to wait for feedback from the OP.

Perl 6 - links to (nearly) everything that is Perl 6.