Yes, I've hit this with List::Utils where there's a version mismatch between the deploy and (apparently) the version pre-installed. Since quite a few other modules depend on it, they don't work either. This was AWS Ubuntu, and I had something likr this:
https://stackoverflow.com/questions/45000585/listutil-c-loadable-library-and-perl-binaries-are-mismatched-got-handshake-key

@TheRealCuran that is the difference between cpanm and carton.

The first can by used either to install packages at root level, or more locally.

carton by contrast wants to create self contained installations. This means:

• packages that originate from perl distributions (i.e. the zip/tar you download) are expected to preexist. Those are never installed by carton, because that would require installing a different perl. Every perl distribution has a package named Module::CoreList that lists them.
• perl distributions must be full. This is problematic on Centos for example where the distribution is split among rpm packages.

I know you can install modules like Encode separately, but I'm not sure if that is a good idea. Maybe some other core modules depend on that older version?

The problem is then: carton is happy to take the latest version of Some::Module, which declares a dependency on an Encode version that is newer than what is in the core modules. Either carton needs to resolve to an older version or it must install Encode's newer package. Having it both ways is not OK.

Apart from that: I've been installing those packages from CPAN for many rather big deployments with cpanm in front and that has been working for years – after all, those core packages declare minimums as well. If an update to, say, Encode breaks another package, then that is either a regression in Encode (eg. forgot to declare a minimum Perl version high enough to satisfy its new requirements) or the other package did something it shouldn't have and just got lucky, that it worked before. In either case there needs to be a fix to one of those packages.

If this behaviour is not good for everybody (I am not seeing a case where it shouldn't that isn't a bug somewhere, but OK), then hide it behind an option like --upgrade-core-modules-if-needed or whatever. Maybe even attach a big warning to it. Or, as an alternative, only consider versions of a package, that are installable.