Ah, I'm afraid you have let your anti-Microsoft bias show, which does weaken your argument somewhat. In fact your argument is really strange, coming from an engineer. It boils down to this:
1/ Microsoft want to re-architect part of Windows to make it more secure.
That is not an established fact. That is Microsoft's claim.
2/ But there might be bugs in the new code, undermining the gains it can offer.
3/ The regulators don't care about bugs or the quality of anyone's code.
4/ Therefore there is no case for allowing the improved architecture and we should continue with an architecture which the owner has identified as insecure and fragile.
For one, I still haven't seen any source that actually establishes that "the improved architecture" was not allowed. As far as I know, this was only about not allowing Microsoft to prevent competitors from accessing interfaces. If you actually have a source for that, feel free to point me to it.
But also, this still is just Microsoft's claim, not an established fact.
Can you see how silly this is? You are probably right that code quality is not the concern of the EU, but security vulnerabilities surely should be! If not, then the EU is the party that needs to do some serious thinking.
No, they shouldn't either. Not in that part of the bureaucracy. Security vulnerabilities are adressed via liability rules and possibly via product quality standards, not as part of antitrust law.
Take your own code. Suppose you can see a fundamental weakness in the architecture that leaves it vulnerable to bad third party code.
This is simply misleading framing. You are phrasing this as if there is a security vulnerability in Microsoft Windows. There isn't. Or, at least not in this particular case. A security vulnerability is something that allows an unauthorized party to compromise the integrity of a system. That was not the case. What you call a "vulnerability" here is nothing more than the freedom of authorized parties (i.e., the owner of the computer) to install any software they want - and that happens to include software that crashes their system, or that contains security vulnerabilities, because that is an unavoidable consequence of having control over your own computer. It is your computer, and the fact that it is "vulnerable" to you installing any software that you want to install on it is a feature, not a bug.
Do you leave it unfixed in case your solution introduces new bugs? (Don't say yes, because no one will believe you).
No, I wouldn't, because that's a misrepresentation of my position.
I would indeed potentially leave it "unfixed", because, in my view, it is not a vulnerability that the owner of a product that I developed can do with it whatever they want.
And also, what I would do is not particularly relevant to what the competition authority should do.
The truth is that nobody's code is bug-free, but to use that as a reason not to close a gaping security hole in your software is absolutely nuts.
There is no security hole in Windows.
There is a new architecture available that should greatly improve the resilience and security of Windows. Yes, there might be critical bugs in it, but we now know with certainty that the existing architecture is extremely vulnerable.
We do know that the existing architecture of CrowdStrike is extremely fragile. That doesn't mean that it therefore makes sense to allow Microsoft in particular to have a monopoly on the part of the system that CrowdStrike screwed up. And that is what you are suggesting. It doesn't follow that because CrowdStrike was bad at it, therefore, Microsoft will build a better product than all other competitors, nor that that is something that the competition authority should be concerned with.
Getting the architecture right is crucial, and improving a bad architecture is crucial. It means you are starting from a better place with your coding.
Yeah. But making it so that only Microsoft is allowed to build the architecture isn't a useful approach to that problem.