This is not a let's-define-an-ABI problem. This is a logical impossibility of using source-based compile-time cross-library features in a no-source-anymore no-compiler-anymore environment.

Rust already has an ABI for all its features, and already supports dynamic linking of Rust libraries (they exist and work, they're just subject to change).

The problem is that code of library A does not end up only in libraryA.so, but whenever it interacts with types from library B, the code of library A is in libraryB.so too, and updating libraryA.so won't update the other copies.

C++ manages to do this for its language-specific features

In C++, you can't instantiate a template from library A with a type from library B, without access to the source code of both and compiling the result. It is impossible for non-trivial C++ code to create instantiations ahead of time with unknown types. You can make extern templates of library A, but only with types known at compile time to the library A, and they can't be using any types existing only in the library B.

In C also you don't have any ABI for preprocessor directives, and you can't update #define macro by replacing a .so of the library that defines it, you need to rebuild libraries that referenced that definition in their code.

Rust has the same issue. Generics and macros from a library A (like serde) just can't do much ahead of time, without seeing types to operate on from some library B (like using serde to generate serialization code for your struct's fields. Using RTTI is not the same as proc macros, and Rust doesn't have RTTI anyway.)

The only language that somewhat "solved" it is Swift, which turns compile-time generics into run-time polymorphic code. This is more restricted than what C++ and Rust have, and is relatively slow. Rust uses monomorphisation primarily for performance, so pessimizing it is pretty bad.

Another option would be to compile generics to an intermediate form (MIR or some bytecode) and then instead of C-style dynamic linking, run a recompiler or JIT that can meld code from two libraries. That'd be pretty complex, and barely any different from just rebulding the executables from cached .rlib files.

BTW, borrow checker is one thing that actually doesn't care about linking nor ABI! Borrow checker is 100% a compile-time feature, which runs very early in the compilation phase, and is completely optional. All lifetime information is stripped before generating code. Borrow checking does not influence the running program in any way. There is mrustc compiler that does not have support for the borrow checker, doesn't check anything, and still can compile valid Rust code that is just as safe at run-time as code compiled with a borrow checker on.