If you were to interview any "standard" windows programmer today i can almost guarantee they know nothing about COM even though WinRT itself is an evolution of COM and .NET also provides COM interop. Only the older senior programmers who have used it directly know of it.
Also no one uses WinUI, if that is what you are implying with WinRT, only Microsoft employees on Windows team forced to deal with that clusterfuck framework after Project Reunion pivoted into WinAppSDK.
What do you think Qt, VCL, FireMonkey, ImGui, wxWindgets, JUCE make use of?
Also you do not need COM to program in C/C++ directly on Windows API since they are all C interfaces anyway. COM is just an architecture you choose to use or not depending upon your needs.
Ever since managed languages/virtual machines became "standard" programming platforms most Windows programmers only write to these. Everything is at such a high-level now that only curious programmers delve deeper into the rabbit-hole.
It is like using ReactOS instead.
All Windows APIs since Vista are delivered via COM.
How much Windows development are you doing actually?
Not that much apparently.
Also someone has to surface Windows APIs to managed languages, they don't appear by magic.
Nope, This right here tells me you do not have much actual programming experience in Win32/Win64 apis nor of Windows Internals. The C-style windows apis are from kernel32/gdi32/user32/etc. user-mode dlls which call into intermediate ntdll/win32u dlls which then calls into kernel mode ntoskernel.exe/win32k.sys. With modern Windows there are another layer of abstractions with "Windows API Sets" (https://learn.microsoft.com/en-us/windows/win32/apiindex/win...) which decouple those user api from their actual implementation dlls.
COM is at user-mode and so interfaces to the first set of dlls only. Since the windows api breadth is vast not all of them are exposed via COM. WinRT uses/enhances classic COM but also calls Win32 api as needed. So Win32 api and WinRT api coexist with the latter providing the "modern" way to api access - https://en.wikipedia.org/wiki/Windows_Runtime But because WinRT is oriented towards secure sandboxed apps many low-level Win32 apis dealing with memory management, thread/process manipulations, system hooking etc. are limited/removed entirely from WinRT api.
For your edification see this detailed older article; Turning to the past to power Windows’ future: An in-depth look at WinRT - https://arstechnica.com/features/2012/10/windows-8-and-winrt...
Your claims must be backed up with references before asking others about their experience. I only see you name dropping and quoting historical data in all your comments which is not relevant to discussing/understanding anything.
That is for new APIs, not extensions of existing APIs.
IIRC, most non-COM methods you'll see for those are wrappers around COM calls. Back when WinRT was promoted as the next big thing, once you got outside of the small circle of WinRT propaganda there was explicit acknowledgement that all of the APIs are actually COM based enabling continued development of non-.NET compilers.
Of course underneath it all, especially once you get to userland-kernespace interactions you go back to combinations of IOCTL, memory mapped IO, some basic object calls and undocumented fun of OpenVMS-derived IPC, but a considerable chunk of that is not exposed or documented for non-blessed programmers.
WinRT is made up of component dlls and therefore exposes functional interface bundles. But the implementation of these components mostly took the path WinRT -> Win32 api -> ntdll (aka "Windows Native api" which is undocumented). But since MS wanted to push WinRT they allowed some paths to be WinRT -> ntdll. AFAIK this is what the mandate/waiver was for.
So you have the current situation that some Win32 apis have no analogues in WinRT and vice-versa. The DirectX path uses "Nano-COM" (a stripped down version of COM) which calls into user-mode runtime dlls which then takes another path to the kernel.
Lets not even get into how .NET projections/interfaces/wrappers do their job ;-)
The key point to know is that COM is only a packaging architecture/framework/middleware for structuring at a user-mode binary level.
It is all quite elaborate and complicated and so making a one-line statement like "everything is COM" is sheer cluelessness.