2008 R2 is the same generation as Windows 7 (I figure they couldn't trick the server market into thinking it was a whole new version, like they have done with the consumers).
And there were two (or more?) versions of 64-bit Windows XP, the first one was for the ia64 architecture (the one Intel made to replace their x86 - or ia32 - architecture, used in some Itanum and maybe one or two Xeon CPUs, and which totally botched any attempts at running standard 32-bit applications - either the hardware part responsible for running 32-bit software was seriously underpowered, or it all had to be run through software emulation, I don't really remember, maybe a combination; the hardware bit was so slow that it was actually faster doing it all in software), the other was made for the more common AMD-engineered architecture (ingeniously called "amd64", before it was generally adopted as "x86-64" and "x64"), who decided to simply slap on 64-bit processing to the already common x86 architecture so as to not break binary compatibility.
Bah, what the hell. Wikipedia to the rescue.

Nah I didnt mean you were out of line or something, just stating.

XP Mode is MS Virtual PC with XP slapped on it and an additional program in the VM that enables it to run rootless (ie. without displaying a desktop, instead putting all its windows among those of your host OS).
Almost exactly the same as VMWare's Unity, with the possible difference that XP Mode seems to enable shortcuts on the host pointing to apps in the VM (if I remember correctly).
As such there should be no difference between XP mode and any other XP installation, other than that you ARE running inside a virtual machine and thus cannot take full advantage of your hardware (most notably graphics), yet, but then if you've got a 64-bit CPU or loads of RAM you cannot do that anyway using a 32-bit OS (like most XP and even many Vista installations).
98 should have been killed and and dumped in a river a long time ago, good riddance.

Like I said a big difference.

There are some big potential problems with the XP "emulation" in XP Mode yes. I reckon most older games will simply be run straight-up, like they are in Vista today.

My best understanding is that this particular release of VPC (probably the last) is that it incorporates a great big wodge of the Hyper-V (read: Xen) hypervisor, thus it should take full advantage of all of your hardware at something like a reasonable fraction of native speed. I believe it's leaving out all or most of the nasty hardware emulation that VPC did (Sayonara, Creative Vibra16! You won't be missed!).
If I've got all that right, and it hasn't changed noticeably since I was reading a few months ago, this puts it sort of roughly between WOW (Windows-On-Windows) and the various full-emulation environments (Parallels) that attempted to pretend to be hardware of sorts.
(I've heard WOW referred to as a VM. I'm fairly sure it's just extra process separation and an encapsulation of the Win16 subsys. (Win32 in the case of WOW64.) So far as I know, that makes it considerably like WINE, but presumably with much better compatibility.)

XP Mode is not meant for gaming, it is meant for business use (this is also why it is omitted from Home Premium, the normal home user version of 7). Virtual PC can't "see" your GPU for technical reasons; it can see the CPU, but that is because both Intel and AMD incorporate hardware-assisted virtualisation functionality into most of their recent CPUs.
You'd have much better success with VirtualBox's experimental Direct3D support. VirtualBox can't see your GPU either as such but passes instructions through in its own manner with no assistance from the hardware.

Better utilisation of the CPU yes, not so much for other hardware.
VPC's set of virtualised hardware is at least a set of REAL brands and models with drivers for just about any OS you can think of (as long as it runs on x86 hardware), unlike VMWare's that requires its own special drivers only available for a select few operating systems.
Earlier versions of VPC (not supporting Hyper-V), and earlier CPU's report the make/model of the real CPU to the VM as well, so it's defintely "seen", and it would be very bad (tm) to give the VM direct unsupervised control of the host's hardware (as it could easily make the host go down due to buggy code running inside the VM, partially removing the meaning of running in a VM in the first place). They'll always go through a layer of supervision and emulation, how thick that layer is is another matter.