Windows doesn't use VS projects. Build system is (well, was when I worked on it) custom and utilized compiler drops from developer division[1]. If you take a look at the Microsoft WDK, you'll get an idea of how the build system works, with "sources" and "dirs" files sprinkled around. VS projects wouldn't work great for yet another reason: pretty much nobody in Windows uses VS. People come from different backgrounds and already have preferences. So vim, Emacs, SourceInsight, SlickEdit and others are much more popular than VS.
Top level directories represent depots (think: repositories) of the SourceDepot version control system (home grown Perforce fork). Directory levels also tend to represent branches, so e.g. WINMAIN has branches for most depots (e.g. FBL_minio, FBL_minkernel, etc.) with additional subbranches following this pattern (e.g. FBL_minkernel_devices).
I liked Windows build system a lot. It's pretty neat how it works, what you can do with it, how you can build whole system or just parts of it, etc. It's not that simple to get build system of this size right, but I think MS actually nailed it.
[1] It has to be like that, otherwise it'd be impossible to support new platforms, like - say - ARM before WinRT was announced.
Between your comment about the dog-fooding of compiler drops, and the raving reviews of VS that I've heard (no first-hand experience, mind you), that surprises me. If nothing else, I would think that having everyone on VS while editing something like the Windows source code would surface VS bugs that one might not encounter in other situations.
That said, I do have a deep appreciation for the pushback against a corporate editor mandate.
It's not exactly true that nobody uses VS. They just don't use it for building windows. I'd say that for debugging and editing source, the majority of windows developers probably have their own ad hoc "workspaces" that define projects for the portions they're interested in, and that's where they do their editing and debugging, but when they actually want to build, they go to a command prompt and use the monster of a custom build system.
VS is not designed for code base this size, because there aren't that many code bases this size out there. Same reason VSS ain't used for code versioning. Having said that - I don't see how having msvc build drops earlier than anyone else and testing it on the Windows code base is bad for the compiler and goes against dogfooding.
Speaking of dogfooding - using unstable builds of VS (the IDE, not the compiler which tends to be pretty stable) for something else than developing VS itself sounds like a recipe for disaster when it comes to something as massive as OS. If you read some OSS mailing lists devoted to low level dev, you'll see that what low level developers actually want is LTS compiler, not some half baked C++ year 2135 early draft compliant turd. This is why e.g. OpenBSD sticks to some old GCC with custom patches.
However it's not weird to be one source tree
(There might be some things off-tree like some tools)
It's certainly debatable and there are advantages and disadvantages either way