Premise

One of my favourite 'tricks'¹ is the possibility of putting code in @INC, as explained in perldoc -f require. Now, the standard way to use it is to return an open filehandle to the wanted module, e.g.

#!/usr/bin/perl

use strict;
use warnings;
use lib sub {
    my $wanted=pop;
    return undef if $wanted ne 'Foo.pm';
    open my $fh, '<', \<<'.EOM' or die "D'Oh! $!\n";
# ---- Begin package code.
use strict;
use warnings;
    
package Foo;
use base 'Exporter';
our @EXPORT='bar';

sub bar {
    print "Hmmm, seems to work!!\n";
}

1;

__END__
.EOM
# ---- End package code.
    $fh;
};
use Foo;

bar;

__END__
[download]

The proposal

Now, it occurred to me that even if, as usual, there are many other ways to do what I'm about to propose, one may want to use this feature to "alias" a package (or better, a set of packages at a time) by modifying $_[1] (in the case of the sub or array form of this 'trick') - and returning undef to let the default mechanism continue the search in the standard locations. But this is not currently possible:

$ perl -le 'use lib sub {$_[1]="Foo.pm"; undef}; use Anything;'
Modification of a read-only value attempted at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
[download]

So I wonder if $_[1] could be made not read-only instead.

I understand that there may be inherent risks in doing so, but

1. I don't see many options for one to inadvertently modify $_[1];
2. the rationale should be that this is a somewhat "advanced" anyway so if one is using it, then he's supposed to know what it's doing.

¹ See e.g.:

• Re: Loading a Module from a Variable
• Re: Using a module more than once
• Re: I'd like to have an indication when the interpreter moves to the next file (using Filter-Include)?