possibly this was a recent change?

Relatively recent. The main change was this one in Perl 5.26.0, released in May of 2017, with some preliminary changes (these) in 5.24.1, released in January of 2017.

There are many .pl scripts and I'd rather avoid having to manually change them all. Is there a way I can go to accomplish that?

What change are you talking about - the include path? One way to add paths to @INC globally is by setting the PERL5LIB environment variable (taking care not to clobber its contents if it's already set).

I'm only going to use this local site to test new code or other things before I implement them on the unix site.

I've worked with Perl on both Windows and *NIX for many years, and let me just say that things are different on both OSes - not necessarily better or worse, but certainly different. Sure, getting Perl code to run on both is possible, but in this situation, it sounds like you've got a test/development server, which you want to set up on Windows, and a production server, which is *NIX. I do have to say that I think you'd be much happier if your test/dev system was *NIX as well, as things will mesh so much better that way - no fiddling with file permissions every time you sync the two, no differences in paths between the two, and so on. You might want to consider setting up a Linux virtual machine on your Windows system...

How do I add a directory to my include path (@INC) at runtime?. For Windows either do it via the UI (a web search for something like 'Windows set environment variable'), or set:

set PERL5LIB = c:\path\to\your\modules;c:\another\path
[download]

Alternatively, create a local virtual machine and mirror your live setup (perl version, OS, data).

Environment variable PERL5LIB can be accessed from the Control Panel

Control Panel 
-> System and Security 
-> System 
-> Advanced system settings
-> Environment Variables
System variables

I agree with the comments about creating a Unix virtual machine to use as your test bed. Even after (if?) you get your Windows test bed set up, you may have to (re)write some of the code to work on both platforms. That could be a project in and of itself. If getting the code to work in both Windows and *nix is your goal, go for it. I think you're asking for headaches you don't need if that's not your goal.

I have several virtual machines that I spin up, pause, clone, and delete as needed for testing. Having a separate machine for a test environment isn't always needed, either, depending on what you're testing. You can create a virtual host on your Unix site and create a copy of your code there (or use version control) to try out your new code or other things.