To summarize, no, it's not necessary; they could have used a single folder, and no, Windows does not present itself differently to a program being run from one location or another.
Well, everybody seems to be throwing in their opinions on this, so I'll toss in my 2¢. Others have already conjectured on the reasons as to why Microsoft chose to create separate top-level folders for 32-bit and 64-bit versions of programs, so I'll leave that part (the best reason was David's explanation that it is as a convenience to programmers). Of course even then, it doesn't quite address the direct question why is this even necessary?, to which the answer is presumably: it's not.
Instead, I'll address the main body of the question
Does Windows somehow present itself differently to a program running out of "Program Files (x86)"?
Not really, but the location of the program can affect the behavior, but not in the way you would think.
When you run a program, Windows sets up an environment in which to run it (I mean in terms of memory, addressing, etc., not just environment variables). This environment depends on the contents of the executable (32-bit and 64-bit programs differ internally). When you run a 32-bit program on a 64-bit system, it runs in the 32-bit subsystem which emulates a 32-bit environment. It is called WoW64 (WoW64 stands for Windows on Windows 64-bit) and is similar to how 16-bit apps would be run in XP using the NTVDM.
When you run a program with or without admin privileges, it affects how it runs, but the location should not affect it (though there are some examples of location dependency like some drivers for example).
(I am using a different computer, so I cannot rely on my browser history to backtrack my steps, but the other day while answering this SU question I ended up at this SO question which caused me to Google PROCESSOR_ARCHITEW6432 which lead to this SO question and this Microsoft blog posting.)
Somewhere along the way, I read a StackOverflow post about how the envirnoment variable
%processor_architecutre% gives different results depending on where you run the command-prompt from (I'll try to find the exact quote).
The answer turned out to be due whether the 32-bit or 64-bit version of the command prompt was run (i.e., from
SysWoW64\). In other words, while the location seems to affect the program's behavior, it is only because there are different versions of the program, not because Windows treats the folder in a special way.
This makes sense because the executable file's contents dictate whether it is 32-bit or 64-bit, so you could put both a 32-bit and 64-bit copy of the same program (e.g.,
foobar64.exe) in the same folder and when you execute them, they will be loaded correctly (the 64-bit version will be run natively and the 32-bit one will be run in the WoW64 emulation layer).
FreePascal allows you to install both DOS and Windows versions and they go in the same folder:
%programfiles%\FreePascal. It manages the different architectures by keeping executable files (
.ovr, etc.) in separate folders and sharing resource files like pictures, source-files, etc.) There is no technical reason that this could not also be done for 32- and 64-bit versions of a program. Like David said, it is just easier for the programmer if they are kept separate (i.e., using variables to make it look like there is only one set of files, etc.)