Then choose one and stick with it.

Or don't use either.

In fact, maybe your team should hold a series of meetings about whether or not you should use any 3rd party, non-core modules that weren't designed and maintained in house if the expectation of every project is that it needs to be a thin layer over yet another piece of code rather than it being optimized specifically for its use and follow its own development path.

Look at the current versions of Mars and Venus on cpan and it's clear that Mars is closer to a low level testbed and benchmarking system. Mars::Meta and Venus::Meta are the closest to actually duplicating code but Venus looks to be optimized to resolve internal config data that doesn't even exist or apply in Mars. Venus is documented for end users. Venus is being promoted to end users. Venus has had a major point oh release and has seen updates since January. Mars didn't even exist until July of this year which begs the question: How could Venus be based on a package that didn't exist for another six months?

Anyway, I'm left wondering why Al (or anyone) should be expected to maintain two different projects just to satisfy a need that doesn't exist. If they choose to do so, fine but having the guts in one codebase that only exists to be the sole prerequisite for the wrapper in a totally different codebase seems silly and over complicated.