Avoid features that aren't portable to Windows, and test on both platforms. I've never noticed an appreciable difference with -T / strict / warnings.

2. Is there any change to @INC or the shebang between these systems I should worry about?

Unless you're using Apache on Win32, the path part of the shebang line is ignored. The paths in @INC are going to be different, but what you probably care about is whether the packages your application expects are there are not. Test.

3. When delivering the application itself, should I also bundle the required modules that it uses?

That depends on your user base. If doing a CPAN install or running PPM is going to be an obstacle for them, then bundle what you need and use lib.

4. What about using the modules as "local packages" under the application directory itself?

See 3.

5. how would cmd.exe (NT/XP) vs. command.com (98/ME) vs. /bin/sh differ in their interpolation in this regard?

Shell meta-characters aren't completely portable across platforms. Beyond that, test.

6. What about operations like open(), sysread(), and system()? Do they need specific "precautions" as well when run on Windows?

If you want to write binary data portably, use binmode() to prevent newlines from getting translated, and use the "network portable" pack() formats. Use of system() depends largely on what you're trying to invoke, and whether it exists on the target platform.

Any insight from those who have done this?

If you run into messy platform differences is some area, consider writing the equivalent of a Java Interface class (or an abstract base class) that hides the differences behind the interface, then write platform-specific subclasses. Write factory methods that cough up the appropriate platform-specific subclass.

This may sound like generic advice, but it worked well on an 80KLOC Perl middleware server with a web front end and a database back end.