While all the platforms I tested (Linux 2.6, Solaris, and Windows XP) have the case sensitive
environment variable table, Windows batch script handles environment variable in the case preserving
but case insensitive way (that is, cmd.exe can get both FOO and foo as environment variables
when it's launched, and the "set" command will display it accordingly, but "echo %foo%" results in
echoing the value of "FOO", not "foo" — this is presumably caused by the behavior of the underlying
Win32 API GetEnvironmentVariable acting in case insensitive way.) Windows users are also
used to write environment variable case-insensitively (like %Path% vs %PATH%), and you can see many
documents on the web that claims Windows environment variables are case insensitive.
So for a consistent cross platform behavior, it creates the least confusion to make the table
case insensitive but case preserving.
In Hudson, often we need to build up "environment variable overrides"
on master, then to execute the process on slaves. This causes a problem
when working with variables like PATH. So to make this work,
we introduce a special convention PATH+FOO — all entries
that starts with PATH+ are merged and prepended to the inherited
PATH variable, on the process where a new process is executed.