Is File::Copy versioned separately from Perl itself? When I look at the CPAN page it looks like File::Copy shares the version number of the perl distribution it is included with

File::Copy is a core module which means that it is bundled and shipped with Perl. However, the core modules do not share their version numbers with the corresponding Perl version. The page you linked contains both the version number of Perl (in the crumbtrail at the top of the main div) and the different version number for File::Copy (at the top of the left margin). For core modules, Perl itself is the dist but each contained module is versioned separately.

So what's happening is that in perl 5.34.0 and earlier, a module that is included with Perl by default (File::Copy) is calling a module that is not (List::Util)? And then perl 5.36 removed this dependency?

Yes, with the exception that List::Util is a core module too. See modules for the full list of core modules.

So in my example, which uses 5.20.0, File::Copy is calling List::Util, but is finding the version installed at /home/user_foo/perl_modules/lib/perl5, rather than the version installed at a location corresponding to (and compatible with) 5.20.0. Is that correct? Is it possible to tell perl to use one path for a specific module but use another path (or set of paths) for other modules?

Yes, this is possible, but also, that way lies madness. If you go down that road, you will make things much harder for you, and you will have to debug lots of weird errors. You are much better served by re-installing a fresh copy of all modules with your current Perl, and keeping your modules (say) in a cpanfile so you can reinstall them quickly whenever you move to a new version.

Perl will not reload a module if it has already been loaded. A first, horrible approach is to manually pre-load all the modules you want from the appropriate directories:

use 5.020;
use feature 'experimental::signatures';
no warnings 'experimental::signatures';

sub preload_module( $base_dir, $modulename ) {
    my $final_name = $modulename;
    $final_name =~ s!::!/!g;
    require "$base_dir/$final_name.pm";
}

BEGIN {
    preload_module('/some/perl5/dir', 'List::Util' );
    preload_module('/some/perl5/dir', 'Scalar::Util' );
    preload_module('/some/other/perl5/dir', 'Another::Module' );
}

use List::Util 'reduce';
[download]

An even more horrible way is to set up a hook in @INC which looks at the file to be loaded and chooses the correct one:

use 5.020;
use feature 'experimental::signatures';
no warnings 'experimental::signatures';

my %module_map = (
    'List/Util.pm' => '/some/path/to/perl/modules',
    'Scalar/Util.pm' => '/some/other/path/to/perl/modules',
);

sub find_correct_module( $self, $module_file ) {
    my $real_module = $module_map{ $module_file } // $module_file;
    open my $fh, '<', $real_module or croak $!;
    return $fh
}

BEGIN {
    unshift @INC, \&find_correct_module;
}
[download]

This will be even harder to debug but allows you to have deep dependencies automatically resolved without preloading modules.

Again, my advice is to do a fresh start and keep a list of all modules you need, and use local::lib and to install all dependencies below a directory separate from the system Perl directory.

When doing this sort of investigation, I find the core utility corelist to be very useful. This has a number of options; here's a selection of examples:

$ corelist File::Copy

Data for 2022-05-27
File::Copy was first released with perl 5.002

$ corelist -v 5.034000 File::Copy
File::Copy 2.35

$ corelist -a File::Copy

Data for 2022-05-27
File::Copy was first released with perl 5.002
  5.002      1.5
  ...
  v5.34.0    2.35
  ...
  v5.36.0    2.39
[download]

Note that some modules have been added then removed from core:

$ corelist CGI

Data for 2022-05-27
CGI was first released with perl 5.004, deprecated (will be CPAN-only)
+ in v5.19.7 and removed from v5.21.0
[download]

If it's important to you, perlhist gives the date of Perl releases.

Modules which are core, but do not have a separate CPAN version, will show perl-<version> as the distribution when you search for them using MetaCPAN; for instance, "MetaCPAN: File::Copy" gives:

Ricardo SIGNES / perl-5.36.0 / File::Copy

On the left-hand panel, under TOOLS, the Download link points to the tarball: 'https://cpan.metacpan.org/authors/id/R/RJ/RJBS/perl-5.36.0.tar.gz'. You can't install this module separately from CPAN.

Modules which are core, but also have a separate CPAN version, show a distribution which is not perl-<version>; it may reflect the module name, e.g. Some-Module-<version>, or it may be part of a bundle of modules under a different name, e.g. Various-Modules-<version>. For instance:

$ corelist List::Util

Data for 2022-05-27
List::Util was first released with perl v5.7.3

$ corelist -a List::Util | tail -2
  v5.36.0    1.62
[download]

From "MetaCPAN: List::Util":

Paul Evans / Scalar-List-Utils-1.63 / List::Util

The distribution name is a link. Follow this to get additional information, including a list of bundled modules.

Also under TOOLS (left-hand panel) there's a "Jump to version" dropdown list: possibly useful if you want to install an older version from CPAN.