I have a nice, dual-core build machine with RAID-1 Raptor 150 disks and 2 GB of RAM -- typically, I can keep working while building in the background on this machine.
However, when using XNA to build the MC2 sample, the Visual Studio window was mostly unresponsive duing the 7 minutes and 14 seconds it took to build. Most of that was because it spent 532 seconds in the CreateTGL stage, during which clicking anywhere in the Visual Studio window did nothing. In fact, I got a task bar balloon telling me that "Visual Studio is busy; please report this problem to Microsoft if it happens often."
I understand that this is a technology pre-view, but I thought I should mention that locking up the editor, for any reason, is not good behavior (it would be a deal killer for me, for sure). I also didn't see the nice thread numbers used when parallelizing the build, although I imagine most of that time was spent waiting for the hard disk. Evenso, with enough outstanding requests, it'll probably get slightly better performance, assuming all the stars align just right.

Unresponsive Visual Studio during build
TivagVCH
Hi Jon, We have noticed this as well and are looking into what we can do to make Visual Studio more interactive when building.
Also some of the tools that are called by MechCommander 2 are very resource hungry and take up as much resources as the system will give it (Which we expect to encouter normally with game development)
Thanks again for the feeback, this is something we will look at.
Peter Senescu
You would rather have CPUs sitting idle and memory left unused
Gilles BECAVIN
Are you serious Imagine having an 8-way 4GB box. Potentially the "system" could give the tools 8 CPU's and 3GB of memory. This you consider normal "with game development"
I strongly disagree.
As for the MC2 release, I could say something about QA; asserts galore after <90 seconds testing even your own built binaries. When building (testing), the tools I experienced bugging out were xp*.exe and due to flaws in the tools (had you included the source we could have fixed these errors for you) and outright bugs, but even then they needed nothing of the kind of "as much resources as the system will give it". Perhaps there are yet more hungry tools I missed.
But for such claimed resource usage, especially if you claim it's somehow "normal", perhaps an elaboration would be in place, to explain what tools here could use "as much resources as the system will give it" and specifically why