What everyone else is doing, COM, XPC, Android IDL, FIDL, D-BUS, gRPC,...

Especially more relevant when going with microservices, microkernels, serverless, static linking (and still have plugins),...

Those are all RPC mechanisms, not an ABI. They exist at a much higher level. You could have an RPC protocol be your only interface to the OS, and that would be a valid design, but would have a performance cost (see the classic Tanenbaum–Torvalds debate)

> Those are all RPC mechanisms, not an ABI

I'm not sure about the others, but COM is an ABI. There's a bunch of stuff surrounding it that is RPC-like but the core specification is just binary layouts and calling conventions. It's arguably more cross-language than the C ABI since it lets you generate type-safe bindings for any language, unlike in the latter where you need to parse header files.

> You could have an RPC protocol be your only interface to the OS, and that would be a valid design, but would have a performance cost

Maybe it would, but I doubt anybody would notice. The whole "everything is a file" concept on unix is basically just this (also X11/Wayland).

Nope, when you use in-proc calls, which some of them do support, they become an ABI as well.

The subset of the list that supports in-process calls and which allows for zero-copy (and, realistically, probably mutually mutable) data sharing of its types is shorter still. I think the useful definition of "ABI" includes more than just API discoverability (aka what D-Bus provides if you take away the RPC system).

Preferably one that doesn't deliberately shoot itself in the face to spite its users just to protect some committee members' egos.