I also pointed out that drivers being open source usually makes it easier for programmers OUTSIDE of the development of the driver to be able to identify problems. The problem with blobs on the kernel level is that the only ones who can "guarantee" that the blob won't eat your kernelspace are the people who develop it. You can't submit bug fixes, nor can anyone downstream fix it to work properly if it's broken. In this case it's not just a fetish nor is it about "edge case."
I actually go by what Linus says is "use what works. It just so happens most the time it's open source." (Paraphrasing.) Unfortunately for now at least on nVidia cards the best option seems to be the binary blob if you want a high quality driver.
As for "edge cases" I'm not going to agree that KMS *or* a framebuffer console are edge cases whatsoever. To even use the native Linux graphics stack now the driver has to use KMS in some way to be fully compatible (Catalyst and the nVidia blob, since they are proprietary, cannot use kernel DRM and provide their own.) *Everyone* who has an Intel chipset uses KMS since Intel only ever provided open source drivers.
Worse still for binary blobs: When Wayland replaces Xorg, at least on the desktop, KMS will be the absolutely mandatory to get a desktop at all on Linux. Catalyst and the nVidia blob won't be able to get us there, it has to be open source drivers unless they finally allow non-GPL symbols to use the kernel DRM stack.
And you'd be surprised how many "desktop" Linux users don't use Xorg at all but instead use things like tmux in conjunction with a high resolution framebuffer. KMS is the only reliable way to make sure the framebuffer sets itself to the native mode of your monitor on the framebuffer (uvesafb and vesafb both can only rely on your card's video BIOS, which for most cards doesn't support a very inspiring number of resolutions, rarely any in the neighborhood of 1920x1080.)
nVidia's released nothing, probably for more IP problems than AMD. It's actually remarkable Nouveau is as high quality (But not as high as the blob, in my experience.) as it is. From what I've seen they lack manpower, organization, and basically any sort of cooperation from nVidia or they'd be pretty successful.
I stand by my assessment of the Intel situation. If they simply made more powerful hardware we'd have fully functional, high performing, completely open video that works and delivers all we'd actually want in Linux graphics:
1. Because it's part of the kernel tree it'll be loaded by udev and thus "just work" without any setup. Catalyst and the nVidia blob can't do that.
2. KMS means no more ugly switch between the console and Xorg, but a smooth instant change. No more monitors going dark for a couple seconds. This is perhaps a small benefit, but it's nice.
3. Probably the best driver to run Wayland on between feature completeness and KMS support, two "features" you rarely see in Linux video drivers together at the same time (Either you have great OpenGL support on your card or you have KMS, at least that's the story with AMD and nVidia for now, Intel gets you both but lacks the hardware capability to really back it up.).
4. Driver both upstream and downstream can fix and adapt.