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}?

I'll quote from the documentation on environment variables. This section needs some cleaning-up...

User-defined environment variables, like PAR_CLEAN, always overrides
the ones set in META.yml.  The algorithm for generating
caching/temporary directory is as follows:

- If PAR_GLOBAL_TEMP is specified, use it as the cache directory for
  extracted libraries, and do not clean it up after execution.

- If PAR_GLOBAL_TEMP is not set, but PAR_CLEAN is specified, set
  PAR_GLOBAL_TEMP to "TEMP/par-USER/temp-PID/", cleaning it after
  execution.

- If both are not set,  use "TEMP/par-USER/cache-HASH/" as the
  PAR_GLOBAL_TEMP, reusing any existing files inside.

  Here is a description of the variables the previous paths.

- TEMP is a temporary directory, which can be set via
  $ENV{PAR_GLOBAL_TMPDIR}, $ENV{TMPDIR}, $ENV{TEMP} or $ENV{TMP}, in
  that order of priority.  If none of those are set, C:\TEMP, /tmp
  are checked.  If neither of them exists, . is used.

- USER is the user name, or SYSTEM if none can be found.  On Win32,
  this is $Win32::LoginName.  On Unix, this is "$ENV{USERNAME}"> or
  $ENV{USER}.

- PID is the process ID.  Forked children use the parent’s PID.

- HASH is a crypto-hash of the entire par file or executable,
  calculated at creation time.  This value can be overloaded with 
  pp"’s --tempdir parameter.

By default, PAR strips POD sections from bundled modules. In case that
causes trouble, you can turn this off by setting the environment
variable "PAR_VERBATIM" to 1.
[download]