Since a list seems to be the style....

1. NT is a POSIX compliant OS. If you are worried about -T then you will need to create a new file assocation on top of the standard associations if you want people to avoid having to do "perl -T script.pl". One thing that seems to be a convention in the *nix world is scripts with no extension. Win32 doesn't like files without extensions. It doesnt know what to do with them, so make sure _all_ you scripts have extensions.
2. Shebang has limited utility on Win32. I don't bother with it with anthing but -l and -i, and even then rarely. Others have dealt with this point as well as it can be.
3. A key issue here is going to be how much binary code you have, either directly or indirectly. The vast majority of Win32 perl users dont have C compilers and arent comfortable with using cygwin/gcc (although this is a viable, but slower way to do things.) This means their only source of binaries will typically be you and AS. So if you are using stuff that AS doesn't keep online on PPM you will have problems. BTW, this usually means that they dont even have make or nmake or dmake. I dont know about PAR, but if I were you I would be making sure that all the modules I depend on are part of AS library, and work with the versions they provide (they aren't usually as up to date as the CPAN ones.)
4. Local modules are IMO a pain. Just set them up to install as normal. This isn't usually a problem on Win32 boxes. There wont be an admin saying "you can't install here". Otoh, this does assume that they have some way of installing. Hell you could just copy the files into the correct location.
5. This question is a little bit hard to understand. Shell level interpolation on the three shelss you mentioned are afaik, completely different. But afaik, people like Barrie Slaymaker and the CPANPLUS boys are all over these issues. Why not review their work and take it from there? I think IPC::Run should do the trick nicely. Incidentally interpolation rules on cmd.exe are very wierd. Dont bother trying to guess them without a lot of time. They are barely documented by anyone, and even the perl source doesnt always do the right thing. (Although I say that from the position of deliberately seeking the error out.)

6. Afaik there arent many traps in this regard. Obviously the issues I mentioned above about interpolation may come into play, but generally I think that if it works in unix it will work fine in Win32.

   I suppose one potential trap is code that has been written without properly using things like File::Spec. If you doing regex based file/path games you might get bitten. Even with File::Spec getting sloppy because part of the output is always "" on UNIX may bite you on Win32. Stick with using File::Spec carefully and you should be ok. This will also make Mac and other exotic OS owners like you.

   Ah! I just thought of one common unix trick that is a trap on Win32: you can't delete a file that is open. Also locking semantics are handled differently.

One of the thoughts I had was to write a quick script (batch/cmd file on Windows, shell script on POSIX, or maybe just a pure perl script itelf, which can detect the OS in place, and perform accordingly) which then can unpack the modules delivered with my application, push them into the right place, and so on, but that has its gotchas also.

Dont do this. There are other people who have already cracked this nut better than you will. If PPM's arent good enough and CPAN isnt a viable solution then use PAR or whatever.

Most of the modules are low-level XML, HTML, IO modules wrapped around some code that is doing a lot of text processing.

I would really make sure that they are available/buildable on win32. A lot of XML stuff that I have tried to install has failed. If AS provides it via PPM then its safe, otherwise id be hesitant....

Good luck.