As long as we're talking about patches, perhaps $& is where the patch should be applied so that split-type matches fall within its realm.
The problem with that would be if someone, somewhere, in existing codebase is performing a pattern match, then splitting something, and then relying on $& still pertaining to the pre-split match. That may be a rare potential, but it does exist. So I guess a new variable ought to be used instead of adding functionality to $& (even if it seems to make sense to do so). Just to make it easier to remember, how about calling this new variable $^&, since its behavior would be quite similar to $&
I'm actually kind of surprised that Perl doesn't present a special variable (maybe a special hash) that contains all of the command line switches used to invoke perl. ...not the switches passed on to the script being executed, but the switches passed on to perl itself. If the hash were called %^C, it might contain data like this:
%^C = (
F => "\t",
a => undef,
n => undef,
e => '# The actual one-liner script',
);