It doesn't matter if the project is driven by Microsoft or not, the cat (of automatically generated language bindings) is out of the bag. E.g. Zig is using the same approach without being an official MS project: https://github.com/marlersoft/zigwin32, and Apple has an automatically generated C++ API for Metal (https://developer.apple.com/metal/cpp/).

In the future, the question won't be "what language do I need to learn to code on this platform", but instead "where are the language bindings for my favourite language".

Depends if one is on yak shaving or delivering code into production.

Being a Borland and ETHZ fanboy has taught me some hard lessons in development effort, when languages don't have tier 1 support from platform owners.

So until Rust is on Visual Studio and Windows SDK out of the box, I rather keep using .NET languages alongside C++ for Windows development.

I think it's just a balancing of where work is needed.

C++/Cx (and it's predecessors) was bad in requiring special compiler support whilst WinRT had already seen real adoption and cppwin32 didn't really give any benefits apart from another backend so they seem to have concluded that C++ devs would easier be supported by something more mature (that needed support anyhow) and then just focus the win32metadata project (That's still alive) on "new" languages.

Adoption by WinDev, nobody else cares after they screwed their customers.

They should all have been fired if it was up to me, we don't pay VS licenses for killing our workflows like that.

WinRT is Windows only technology, who cares about extensions.

Plenty of people don't have any issues with GCC and clang extensions, or macOS specific ones like Objective-C++, or TI, or ARM SDK, or whatever fancies their party, only MS ones are bad.