The WinRT ABI does implement some new features, yes - but they’re all still implementable with nothing more than standard C# code with no special support from WinRT itself (in fact, the WinRT ABI integration is being stripped out of the runtime and cswinrt is the way forward).

C++/CLI ultimately still uses the same features the runtime uses for p/invoke calls, though it uses slightly different IL to transition to native code since it doesn’t have to worry about an external ABI within a mixed mode assembly. Sure, there’s a whole compiler that supports this weird mixed mode world from a language perspective - but it’s really boring at runtime.

All of that doesn't change the fact that there is tooling in place, and language features (e.g. dynamic for COM, upcoming C#9 improved native FFI) to ease interoperability between managed and some level of C++.

Something that no UNIX does, and we only find similar ideas in Swift/Objective-C++, IBM language environments, and the old OS/2 SOM (Smalltalk/C++).

While everyone else just writes glue code with C like interfaces, as if the world has hardly changed from UNIX V6.

Purists may hate it, but as a toy project I’ve been working on making a stripped-down version of the WinRT concepts that runs on Linux (well, anything with a c++17 compiler and a dlopen function provided by a linker). The guy behind cppwinrt started work on the Xlang project in a similar vein, but it’s currently not being worked on so I figured I’d give it a shot.

I agree that C as the lowest common denominator sucks.

Good luck with it.

Project Reunion seems to have rebooted everything, which is most likely the reason for it to have stalled.