I'd suggest you both watch Building Windows 8 #1 which demonstrates how how the new UI works. Briefly, it runs over top of the desktop and you can seamlessly switch between the two or even run new and old programs side by side. All systems running Windows 8 have access to both UIs. ARM systems will be the same as x86 ones except for the obvious lack of x86 compatibility (unless Microsoft has some secret solution for this they haven't revealed yet).

It's also worth noting that tablet-style Windows 8 devices will include real ports for USB and HDMI and whatnot (unlike the iPad) so you can turn any of them into a traditional PC experience; you're never locked down to the input methods a Windows 8 device was built with.

I posted a while back with system specs for a unit I designed pretty much specifically for this kind of thing (though it could run newer stuff okay too,) I just couldn't build it.

And as for the ARM computer listed for 25$, a good idea, but why not go whole hog and integrate it into a keyboard already, like the old/new Commodores? For a decent keyboard it might jack the price up to 50 bucks before you'd make a profit on it, but the increase in working room would mean better heat distribution and easier after market modding/upgrading. Take one of those things and sub in a gig of RAM and any HDD and you'd be more than set for an old-school gaming rig that would be ready to go.

Because you don't have the games compiled for ARM and running a virtual/compatibility layer on top of it is too resource taxing for ARM to be able to do it.

I wonder just how much it would benefit you having access to source code with the average older game.
I admire the developers that created them and I certainly don't want to lessen their work, but I'm not sure how many of them followed what you'd consider proper practice today.
Sure, if there was a concrete separation of application layer and operation system level dependencies (everything from allocating memory to displaying graphics and getting input) you could re-use a considerably large amount of the source code, but I'd be surprised.
Plenty of these games were created in the area of procedural programming.

Each day a game becomes older.

NEVER GONNA END

Yeah, I've seen that. Doesn't counter the option that it can be an easily-disabled/enabled application similar to the media center interface.

Id's source releases have all been vanilla C + assembly thus far. Judging from the proliferation of source ports, it doesn't seem to have hurt them.

I think that's pretty much inevitable when you're trying to push the limits of what the hardware can do. I remember seeing a video of the lecture where the original creator was explaining the development of Pitfall. A lot of the things he was doing were nuts by today's standards, but they were necessary in order to make the game run in a reasonably decent way.

Keyboard and mouse will never be supplanted by touchscreens. Touchscreens are fine for accessing existing material, but for creating it? Never. And as for games, a touchscreen is a very limited interface.

actually, MDK is probably a bad example. You might not be able to run the windows version, but emulating and upscaling the console versions should be pretty feasible

Oh bugger. How about Shogo then? Or Ground Control?

Time'll tell :)