With both perls in turn, issue the command perl -V (with an uppercase V) and notice the list of library search-paths. This is the current combined list .. the content of @INC .. as taken from all sources including PERL5LIB.

If you are dealing with two different-generation Perls, as here, these lists ought not to intersect at all. You need to build Perl yourself to do this, in many cases, since the last few entries in the list are hard-coded at compile time. That’s my rule-of-thumb opinion only ... the safest and most reliable course, although perhaps the most time-consuming since it studiously starts with nothing in-common with its surroundings.

The issue, of course, is XS ... C-language code that is invoked by a CPAN module. This stuff goes to the heart of Perl, the so called perlguts, and if it was written for a different Perl it just won’t work. Modules will detect what version is being used at the time that they are installed, and will install themselves accordingly, but if the @INC lists overlap, a subtle mixture of apples and oranges may still occur.

“Older software” tends to be more problematic since it uses “older modules,” and Perl, like all language systems, does evolve over time.

Yes, those @INCs do intersect to the extent of my PERL5LIB. Which, obviously, is what is causing the problem with that 5.10 /usr/bin/perl. I'm just not sure how to deal with having a PERL5LIB together with scripts (that I didn't write) that call the system perl. Maybe the answer is "don't".