How about this - every time a problem like this is found, the affected component is rewritten in Rust.
Kinda like how a bug should ideally be fixed by reproducing the issue with a unit test first - the test ensures that particular problem won't come back.
AFAIK that's possible for C - a project can be rewritten in Rust one function at a time - but I acknowledge it may not be possible or practical for C++ or other languages.
Thing is, there's going to be tons of old C in Windows that is perfectly safe. That code doesn't need to be changed - and with this model, it wouldn't be. What needs to be changed is components like SMB which has been the source of a few high profile vulnerabilities before.
When Rust calls into C code it completely loses almost all of its safety guarantees. Having a codebase which is half C and half Rust sounds worse to read and reason about than all either.
Additionally, most Windows code is C++ with Windows specific language extensions (COM, Structured Exception Handling, and others).
I think most C++ code should be rewritten in Rust library by library, but most software is not properly constructed as a series of libraries. And asking a business to rewrite working code in a brand new language instead of fixing a buffer overflow is a difficult ask.
Microsoft is already had an internal Rust summit,
https://twitter.com/ryan_levick/status/1225837057186000896?s...
and are doing other experiences as well,
https://www.infoq.com/news/2019/11/microsoft-exploring-rust-...
https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-win...
Kenny Kerr, the original author of C++/Winrt, which replaced C++/CX, has now turned into Rust.
https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/
They are also motivated to actually make C safer, with Checked C project, something that ISO C doesn't seem to care that much.
https://www.microsoft.com/en-us/research/project/checked-c/
As per MSRC advisory, new code should be a mix of .NET, Rust or Core Guidelines compliant C++, depending on the use case.