But even on *nix, root user can still modify poor Joe's scripts.
This probability is low, but it equals zero with in-memory unpacks.

Windows users are 99,99% work under administrative privilegies, so replacing /tmp files will be easy for them.

Yet, /tmp space could be full.
Don't tell me that entire system will be badly functioning in this case.
Par will not be working in this case, but other programs will...

Other security risk - is that PAR reuses same /tmp between runs,and this, IMO, could also be busted.

Addition: - another one, when PAR remains its files in /tmp after finishing the program, this means the more program I'll run the larger /tmp will be, and I dislike this.

Okay, I need to address this eventhough I think we are getting somewhat off-topic now. Your points aren't totally off.

• You are right: PAR runs on *nix, Windows and Mac OS X at the very least.
• The root user being able to modify other users' files is a feature, not a bug. The root user can replace /usr/bin/perl with /home/malicioususer/bin/rootkit anyway! So if your root account has been compromised, talking about the security risk of replacing files in /tmp/ is absolutely pointless.
  The comparison to in-memory unpacks isn't helpful either since the original executable (and any signatures thereof) could have been modified by the root user.
• Windows users having admin priviledges is a bug in Windows + a bad decision of the system administrator. Now, to be honest, you describe the real world situation well. What you miss, though, is that the same point I made above about replacing the executable applies as well. If you control the executable, replacing its contents after unpacking is much harder than doing it up front.
• The --clean option makes sure that the cache area is cleaned after each run.
• PAR honours an environment variable to set alternative cache paths. So if you dislike /tmp because a) it might be full (which it should not be!) or b) you want to use a "secure" user path, you can do that.
• Other programs might work or might not if /tmp is full depending on whether they use temporary data on disk or not.

Furthermore, if only in-memory unpacking is possible, packaging some libraries that do their own dependency checking using the file system would not be possible. A hybrid solution, however, would be even more complicated than PAR is already.

I don't think we're off-topic. My first reply to OP was almost off-topic, because instead of curing the problem I proposed using commercial packers etc.

Returning to your list, I agree with it, with all items in it.
If root account compromised and windows admin were bad - then situation is bad enouth to even not care about few more items.

But unpacking source into filesystem is just worse than in-memory unpacks.

/tmp files are like dirt that some program forgot to clean after its run
As another example, 'perldoc' also a dirty program on Windows, and I wish it change its behaviour, but I have no resources to change this.

The situation is very similar to a vacuum-cleaner engine that is noisy and makes dust due to large air flows.
You explain that it is dirty and noisy enough already all around so we can agree additional noice and dust almost un-noticeable. Bur I still prefer silent and clean vacuum-cleaner.

I have very deep respect on PAR, and its author, and maintainers, and for you personally, you all do great job on providing simple solution, which makes commercial packagers to live harder - and this is a good thing.
But looking at situation differently - there is a better approach, which PAR can not do (due to some technical reasons you just said)

With really large regards,
Vadim

PAR honours an environment variable to set alternative cache paths. So if you dislike /tmp because a) it might be full (which it should not be!) or b) you want to use a "secure" user path, you can do that.

Which env var is that? $ENV{TMP}?