Is that a likely problem for the kernel, actually? Given that there's no API stability, and the fact that syscalls are an explicit ABI anyway, I don't see how that'd matter for linux?

(not that I'm arguing for C++ in linux or such)

When using C++, you also need to take into account the compiler ABI.

Does that really matter in the context of the Linux kernel, seeing as GCC is the only supported compiler currently?

Sorry, Just my sour grapes.

Recently created a third party SDK DLL in c++ and could not pass c++ types natively (unless you coupled to compiler and maybe version of compiler).

This is C++ on Windows for you. On Linux, most compilers follow the ABI that GCC created, which has become very stable. I actually cannot name a C++ compiler that doesn't follow that ABI.

Actually, Linux nowadays uses the Itanium C++ ABI (even on non-IA64 architectures), and AFAIK it was created by Intel, not GCC.

I stand corrected. Indeed, the Itanium ABI defined by Intel is the base.

The important part is that it is used by most, if not all, C++ compilers on that platform.

Which is why any Windows developer that wants to export OO libraries uses COM instead, with the benefit that any Windows compiler that can speak COM is able to use the library.

UWP now even supports generics and actual inheritance.

Kernel modules?

One can use the C ABI with C++.

How does that work with templates, overloading, operators, etc?

They aren't exposed to ABI surfaces. Only C compatible stuff would be.

Cf. e.g. Microsoft's CRT implementation, which uses C++ by now, but still exposes a C API.

On Windows that ABI is COM, on Windows 10 it was updated to UWP and is quite feature rich, even if it doesn't support 100% C++ features.