After sleeping on this (for quite a while), I'm pretty confident that
the attached patch gives `compile' a sensible behavior in the presence
of a buffer-local `process-environment'.

Specifically, whenever `compile' is called from a buffer where
`process-environment' is local, the *compilation* buffer inherits the
original buffer's `process-environment' and `exec-path'.  When
`process-environment' is not local in the buffer from which `compile'
is called, any local values of those two variables are killed in the
*compilation* buffer as well.  (There's no check for buffer-localness
of `exec-path' because it's usually misguided to keep it out of sync
with PATH.)

Concerning possible interactions with Tramp, I think the conclusion from
what Michael said previously is: if your buffer is remote, then don't
mess with `process-environment' and set
`tramp-remote-process-environment' instead.  If that is a requirement
imposed on the user, then this patch is free of conflicts with Tramp by
decree.

Still, there is one case, which might be quite specific to my personal
workflow, where I get a problematic interaction with Tramp.  I'm often
editing files locally that I can only compile or run on a heavy-duty
remote host.  So I call, from those local buffers

(let ((default-directory "/ssh:remote-host:/path/to/mirror/of/project"))
  (compile "make"))

With the attached patch, a buffer-local PATH value will leak to the
remote machine, which is almost surely the wrong thing to do.  I've
suggested one solution for this on the Tramp side (using
`tramp-process-environment' itself to block certain variables from
being exported to the remote).  I believe Michael wasn't convinced
this is a good idea.  In any case, there's another solution to this
problem, which is to replace the above by

(let ((default-directory "/ssh:remote-host:/path/to/mirror/of/project"))
      (process-environment (default-value 'process-environment))
  (compile "make"))

This is an okay hurdle to introduce, because it is already needed
anyway for functions that starts a process _without_ changing buffers
first, such as `shell-command'.

I hope this makes sense to everybody and can be merged.  I'd also hope
that the present handling of env vars can serve as a model to be
adopted by most commands that switch buffers and then start a process
in this new buffer, such as the `run-<program>` commands.