Sure, but the C standard is the wrong place to do anything about the "problem".

Also IIRC it was really only UNIX which had this "whatever our C compiler does" mishmash. On most other operating systems it was the other way around, C compilers had to implement whatever calling convention the OS already had defined before there even was a C compiler for that OS (for instance early Windows version used a PASCAL calling conventions, and others (CP/M, DOS, AmigaOS...) some random rules that were most convenient for handwritten assembly code).

PS: and yeah I know that other article (or rather: incoherent rant). It's basically a lot of barking up the wrong tree.

It's barking up the right tree. I don't want to say more, because that would tip off competitors and I'm just a lone wolf working on this.

> OS ABIs aren't independent of the language.

I'd push back on this a bit. The ABI is "put the arguments on the stack this way and jump to this address". The fact that it's easy to do in C doesn't really make a difference, or make that process "C specific" at all, any other language would need to do the same thing.

If you require those arguments to represent rust objects or be reference-counted in some way, it would impose more restrictions on the caller, not fewer.

Rust basically would need to specify the interior memory layout of basic types like Result or Option. But to be pedantic, not even C has a standardized memory layout for structs, only some accidential common conventions that work for some types but not others