it's great to see that i've already gotten some feedback! i'll go ahead an provide some brief comments now:

Jerry and Jamie asked about msbuild support for VC in whidbey (the upcoming version of VS). i'll talk about this more in an upcoming entry, when i get to upcoming features, but the short version of the story is that, in whidbey, msbuild will not include first-class support for VC projects. we will be shipping a separate command-line builder "vcbuild" which can build VC projects and spawn out to msbuild to build other projects and mixed-language solutions. in fact, you can download a VS.NET 2003 version of vcbuild.exe now, from www.gotdot.com/teams/cplusplus. again, i'll discuss this further later.

Gareth asked about some his pet peeves in VS. while i don't work on any of the areas he mentions, i must say i couldn't agree more with his comment about the so-called full-screen mode in VS. VC6's full-screen mode was great and really was "full-screen". it didn't make it into VS.NET and instead we got a version that is nowhere near as good. unfortunately there aren't any plans to get this feature back, AFAIK.

as to Stephane's question about why we don't provide a forwards compatibility "export project" feature, it is more about resources than a marketing or technical reason. we have limited time and developers and lots of feature/fix requests. this feature has been a low priority in the past because there were not many requests for it, and it is difficult (if not impossible) to do it such that it works correctly all the time. lately forwards compatibility has been a bigger request, but to be honest i don't think we'll be addressing it in whidbey.

lastly, Chris is wondering why the XML VC project format in VS isn't "real" XML. actually, it's not the XML that is bad (although there is one serious flaw where the newlines in multi-line commands are not stored correctly), but the XML reader that we use. when the XML reader code was written msxml provided two parsers: a DOM-based parser that was rich in functionality but slow and a high-speed bare-bones parser that leaves how the XML is interpreted up to the developer, but is MUCH faster. the way in which the VC loader code works requires certain attributes (in particular, the "name" attribute) to appear in a certain order. (the "name" attribute is used to create the object on which the other attributes are set, so it is needed "up-front"). so i guess the answer is that this is mostly the side-effect of trying to optimize the loader for very large projects. hope that answers your question, Chris.