Name one. At the same time, explain why my "C:\WINDOWS\Microsoft.NET\Framework" folder contains the following folders: v1.0.3705, v1.1.4322 and v2.0.50727? Surely if your claims of backwards compatibility where not make believe, only the later of the three frameworks would have to be installed?
Your assumption is true, you only need the latest version of .Net installed, and the assembly will compile against that runtime.
However, .Net applications have a "preference" to run on the version they were compiled on. If you happen to have that version on your PC, it will actually compile under that frame work version and run alongside other assemblies. If the version it was compiled under isn't present, it will execute under the latest version of the framework. Or, you can specify via configuration file to target some middle version of the framework if you wish.
That said, it's possible to make applications on an earlier version that are not forward compatible. As far as I know, this is only an issue if you start using methods and classes that are not deemed for public consumption. Unfortunately, unless you have a re-factoring/development tool add-in such as resharper, those "forbidden" methods are not entirely obvious unless you look into the documentation. As long as you're not committing these crimes, you should never have to redirect an assembly to compile on an older version.
Not to say MS's JIT compiler isn't good, it is pretty good, but for things like games where performance is critical I would much rather the code was pre-compiled.
Unless you're doing a lot of late binding, or late references on assemblies, all of the compilation will occur at the beginning of the application's life time. Most games already have a "loading" phase for bringing in content.
It probably wouldn't be a bad thing for .Net to eventually have a compiling splash screen (ala java) for this purpose. They could take it a step further and allow it to be customizable.
Also, as multi-core processors become the norm, I'd expect the JIT process to eventaully sort dependencies and multi-thread the compilation process.
I think Java is a better bet. Not only has it been out longer (and thus more throughly tested), it's also more widely adapted.
I'd be fine with that. Any intermediate byte code "language" that JITs to allow for and eases the headache around deployment to other platforms works. As long as I don't have to program in Java, to leverage their compiler, I'm happy. :)