Either way, it'd be great if one could implement efficient GUI's (and full apps more generally) on Android in C/C++/Go/Rust without having to generate JVM bytecode on the fly (or like Xamarin does: at compile time).
The problem with conventional C ABI is that it's just too low-level to produce good wrappers. I mean, all you have are global functions, structs, and data and function pointers. There isn't even a standard string type! (you can say char*, but there's the need to deal with lifetime issues - who deallocates what).
So in practice you need the C ABI, plus all those conventions, like how an "object" looks (i.e. how you do things like method dispatch or type queries), how a callback looks, how strings work etc. And all those conventions are expressed in terms of that basic C ABI - but they also have to be standardized, and they become ABI of their own, like COM and WinRT.
And you also need a convention/standard for metadata, for those wrappers to consume, and for any sort of runtime magic like property bindings - like typelibs for COM and metadata assemblies for WinRT.
What's really needed is some standard higher-level ABI (that does things like classes in a sane way), but which is made out of the existing C ABI building blocks in a manner that allows any existing language with C FFI use it. We can then add a new FFI layer that maps higher-level concepts better, but everyone can still play regardless.
This is exactly what COM was, and what its current evolution, WinRT, is. Any language that can do C structs and function pointers can ultimately do COM/WinRT, but it establishes things like lifetime semantics (refcounting), runtime metadata API, standardized futures etc on top of that. Then languages take that and map it to things that make sense there.
But it needs to be a shared public spec, preferably standardized.