Then raise a bug or a patch against the module(s).

Unless the modules explicitly documents that it uses whatever value you assign to $/ or $\, eg. Tie::File, then no module author has the right to either rely upon some default value, or modify them except for local use. That right belongs exclusively to that author of main::main.

Even if you scope and localise modifications to these variables, if you also need to call a module's functions or methods within that scope, you will break them if they make assumptions.

Module authors should never make assumptions about or permanently change the environment they will inherit. That privilege remains the exclusive preserve of the author of main.

What you're suggesting is a return to The Bad Old Days, when module authors couldn't even count on arrays starting at 0 because you might have changed $[. That sort of thing is frowned on these days, because it made writing modules totally unmanageable. A module author has every right to expect that magic variables like $/ will be at their default values and a programmer who fails to localize changes in these variables is the one at fault for the trouble caused.

For reference, see MJD's Sins of Perl Revisited.

A module author has every right to expect that magic variables like $/ will be at their default values ...

Absolute unmitigated rubbish!

If a variable can only take one known value, it is called a constant. If a module author want to use a specific value for $/ or $\, it is his responsibility to ensure that he has that value: local $/ = '\n"; or whatever. Just as your authority figure, MJD does in his module Tie::File:

## from _read_record() in Tie::File
  { local $/ = $self->{recsep};
    my $fh = $self->{fh};
    $rec = <$fh>;
  }
...
    unless ($self->{rdonly}) {
      local $\ = "";
      my $fh = $self->{fh};
      print $fh $self->{recsep};
    }
[download]

and a programmer who fails to localize changes in these variables is the one at fault for the trouble caused.

More of the same.

You are processing a fixed record length file. You set the record separator to that length and loop. Within that loop, you call some functions or methods from within a module.

What you are suggesting means that you, as application writer and code owner, now have to undo your requirements before you call each function or method--regardless of whether those modules make use of those variables because you don't know--and restore them afterwards, and every time you call those functions, in order that the module writer can be lazy.

use Some::Module qw[ funcA ];
use Someother::Module qw[ funcb ];

local $/ = \64;
while( <$fh> ) {
    ## do stuff
    {
       local $/ = "\n";
       funcA();
    }
    ## Do stuff
    { 
        local $/ = "\n";
        funcB();
    }
    ## Do stuff
    {
        local $/ = "\n";
        funcA;
    }
}
[download]

And you want to do this for every function or method? Regardless of whether it makes use of these variables, in every module you call, and everytime you call it? You're nuts. You have completely inverted the burden of responsibility here.

If module author needs a specific value for one of these variables within a subroutine or method,

1. they know they need it;
2. they know where they need it;
3. the scope of the need is naturally bounded by the subroutine;
4. they only need do it once;

Any other conclusion defies rationality.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."