But later in this thread it was made clear why no one would do it this way because you would need to create .par files for each supported version of Perl and for each platform for that dependency... pain in the neck :)

Check out PAR::Repository and/or PAR::Repository::Client.

More specifically, before discrediting PAR for what you want, you might want to read it's documentation. It contains this snippet:

use PAR { repository => 'http://foo/bar/' };
use Module; # not locally installed!
[download]

P::R::Client even has an auto-upgrade mode. Furthermore, for generating large sets of reusable packages, you can use PAR::Dist::FromCPAN or PAR::Dist::FromPPM.

Whoh, whoh, whoh tsee.. I never discredited PAR in any of my posts, in fact I mentioned it as a possible solution/analog to eggs. I don't think you are reading the posts properly, you're thinking about it in the wrong way. It's not PAR at all that's the problem. I've been programming in Perl for 12 years as a bioinformatician/computational scientist in academia and the biomedical research industry where Perl has been used heavily for that entire same time and I've never seen any open-source Perl-based project/application/system/server that when you download and run the setup it automatically fetches .par files for each of its dependencies, puts them somewhere and uses them transparently when running itself (analogous to what I wrote in the OP about Python and eggs for this open-source Python server I'm using).

If this does exist as you indeed say then it's not at all common. And that was the point I was making, not that PAR isn't a perfect solution for that, but that this style of dependency management just isn't commonly used and then if people don't see it they won't do the same when they are writing their next Perl project. So this goes back to my original question why you see eggs a lot in Python and don't see pars or anything like that a lot in Perl and many monks nicely explained in this thread as to why.