(sigh) Okay, we can do point by point.
You're comparing apples and oranges.
Consumers -- the people using the software -- are comparing desktops to desktops. It doesn't matter why your brakes failed.
I've literally never, not once, in my experience with my own machines, my co-workers' machines, or my friends' machines seen a Windows box be brought down by a video driver upgrade -- ATI, nVidia, whatever. But everyone I know who uses Linux (myself included) has found themselves doing "lynx google.com" after a video driver upgrade.
Have you ever tried upgrading from one version of Windows to another?
This is a more complex issue. See, I don't have to upgrade Windows to get newer versions of software. Modulo backporting trickery, that's not true of Ubuntu -- if I want a newer GCC or whatever I either a) build from source, destabilizing my packages or b) do a release upgrade, breaking my machine.
I expect I'm right in assuming that the failures you experienced were related because the machines that failed shared a single characteristic that caused the failure.
This is completely false. I have contractual obligations not to talk about the hardware too much (and yes, I see where that's leading *rolls eyes*) but the machines are almost completely heterogeneous -- no two share the same processor, there are a variety of both ATI and nVidia cards, etc. Failures were rampant. We suspect it was because of a regression with the new dm's compatibility with LDAP'd network shared home directories. Complete showstopper with no permanent fix that doesn't cripple parts of the system.
Those would be problems you've already solved. In the rare case that they haven't been fixed in the new release, you just pull the documented solution out of the service history and apply it.
Funny, the guys running Windows upstairs don't need a service history (to a rough approximation). Are you listening to yourself? You're seriously suggesting it's okay to have to document getting a consumer machine running. We document install procedures on supercluster nodes with exotic hardware. That shouldn't be necessary for desktops with commodity hardware.
This is what I'm talking about when I say cliched and outdated. Canonical is not a charity that fixes problems based on how sexy they are. They're a business that pays programmers to fix the unsexy problems their customers actually have.
Well, yeah, that completely agrees with what I said, because Microsoft has been paying thousands of developers for decades -- there are billions of dollars and hundreds of thousands of man-years of experience invested in Windows. Some of that is on the same 'fun' aspects of development that FOSS has taken care of in the development of Linux. Others are covered by the sheer competence of the people drawn to Linux development. But a lot of it isn't covered at all, and Canonical isn't even a drop in that bucket. The last 10% takes 50% or more of the work, and Canonical doesn't have anything like the funds to pay for that -- it's borderline dishonest to suggest otherwise.