I'm planning on getting Windows 7 through this offer, and I don't know which version to get.
I don't have a 64 bit computer right now, but I'm planning on building one in the next year or two.
My question is: do I get the 64 bit version and sit on it until I get around to building a computer that can use it, or do I get the 32 bit version that I can use now?

Thats no reason to go crazy and knobble yourself by making near future games impossible to run, thats a reason to dualboot with XP or 98SE. Shit, all a virtual machine developer like VMware needs to do is get a license to run the firmware from a geforce 2 or something and they'd have the ultimate retrogaming platform

The OS limitation is due to how OSes are coded. A 64-bit OS is coded in 64-bit, but for backwards compatibility there is 32-bit emulation. With 32-bit Windows you get a 32-bit OS with backwards compatibility 16-bit emulation. Only one emulation is present in the Windows OSes.
What I don't know is why you can't have both 32- and 16- bit emulation, but it might just be to keep the OS tidy in it's build rather than making it more complicated with even further emulation.
But yes, if you really need 16-bit capability now, go with Aliasalpha's suggestion of dual boot.
EDIT: Anyway, let us hope that those good old 16-bit games get the GOG treatment and are made compatible with 64-bit Windows!

I'm running 64-bit Windows and I'm going to set myself a little challenge.
Wine is designed to run Windows programs on Linux. You can run 32-bit Windows apps on 64-bit Linux.
Wine is also cross-platform. I'm going to attempt to compile Wine on 64-bit Windows and see if it runs a 16-bit executable.
Wish me luck.

I was not successful, but only because of a wrong configure flag. I actually just compiled Wine for a processor that doesn't exist; now that's an achievement.
I talked to a Wine dev and only the DLLs and Wine programs (WineD3D, Wine DXDiag, winecfg etc) can be actually be compiled for Windows. Wineserver which is the fake NT Kernel that Wine requires cannot be made for Windows simply because there's "too much Linux" in it.
That said, I don't believe that Wine on Windows would require Wineserver. I believe that only the DLLs would be required, but that raises the question "Just how do you use them?"
I'm going to look into using AndLinux, which is a minimal port of CoLinux; it's actually a miniature Linux Kernel that runs on Windows, effectively making Linux programs work on Windows. I'll attempt to build Winedows again if I can figure out the right flag for the configure script and then see if I can get an application to use Wine DLLs instead of Windows DLLs.

Here's some reference material to take a peek at....
http://lwn.net/Articles/316536/
http://wiki.osdev.org/Long_Mode
http://en.wikipedia.org/wiki/X86#64-bit_Long_mode
http://en.wikipedia.org/wiki/X86-64#Operating_modes
When the CPU is told by the OS during the boot sequence that 64bit code will be executed it enters 'Long Mode' ... in Linux you can check if your CPU is 64bit capable by looking in /proc/cpuinfo for the 'lm' (long mode) flag.
In Long Mode there is an extra set of CPU registers that get enabled but the part relevant to the question above is that a number of cpu instructions for v8086 (the 16bit compatibility 'mode' in 32bit cpus) are dropped in long mode - for efficiency sake.
So it's not a windows choice to not run 16bit applications on 64bit windows. It is an system architectural issue that 16bit applications cannot run on a x86-64 cpu running in 64bit mode.
So if you have a need for 16bit applications still you need to run in 32bit - note that Dosbox gets around this as it is an emulator and a 32 or 64 bit Dosbox still emulates the same old 16bit 486 era CPU... and ScummVM is similar to that (not emulated but the executable rewritten in 32/64bit).
Edit: Oops the above isn't totally true.... based on that operating mode chart it would in principle be possible to run 16bit applications on 64bit windows... but it is linked to why you can't. The windows 16bit subsystem (ntvdm) is based on using v8086 mode which is only available in 32bit cpus and is not possible in 64bit cpus. Microsoft would have to rewrite this virtualizing much of the CPU to support the dropped instructions and effectively emulate a 16bit CPU anyway.....
See this article in addition to the previous:
http://blog.delphi-jedi.net/2009/10/30/why-16bit-applications-cannot-run-on-windows-64bit/
Edit2: Bit of research shows that 'Windows XP compatibility mode' in 64bit Windows 7 is a 32bit windowsXP instance and can run 16bit applications... So if you have a system that can make use of that compatibility mode (compatible CPU and premium/ultimate windows) you can use that for your 16bit apps.

Thats forward planning there, as soon as that CPU is made you'll be sitting on its very first application!