I think the very first problem was Novell's imagining that Microsoft would provide a stable, sensible and properly documented API for anything, ever. Much less a new piece of software in a new operating system.

All the average customer cared about was that your app was 32 bit and used the new style controls and dialog boxes. Trying to tightly integrate into a bunch of beta software leaves you well exposed to have Microsoft stab you in the back. And if you were a direct competitor to any of their products they would, of course. Even in '94 I had the good sense to know that.

The fact that windows update performed in a way entirely contrary to its users explicit instructions and Microsoft's documentation is by no means a "red herring."

Microsoft tried to downplay the issue by saying that the update was good and proper, was most definitely harmless, and the closest they came to accepting responsibility was that they "could have been more transparent."

Well now it turns out that the update in question was not harmless at all. A misbehaving update which can kill the auto update functionality under some circumstances is bad, but forgivable. But now it's all the more a slap in the face that this was also the one update which was invisibly declared non-optional by Redmond.

Technical flaws happen. Anybody using MS products for any length of time has probably become conditioned to accept them. But a security policy blunder like this is a much, much bigger issue. That you think the easily fixed technical problem is the only real issue here is simply bizarre, and inconsistent with just about every security researcher's opinion on the matter that I've read.

But let's put your "red herring" idea to the test. Let's see if Microsoft forces the fix to this problem on their users in the same way that the forced the update that caused the problem in the first place. I suspect they wont, meaning at least Microsoft got this one correct, even if you missed its significance entirely.