> but is the term ABI new

No, it is age old. The thing is that it is only "a thing" to embedded native developers and library authors.

The general concept is that the programming language "API" doesn't define how the dll/o/a/la/lib/so/dylib "loader" look for "symbols" in the file. If you example, I do:

    enum {FOO, BAR};

and next month I change it to

    enum {BAZ, FOO, BAR};

then everything will still compile, but if I execute an older program with my library, it still thinks FOO is 0 and BAR is 1 while it's no longer the case. It gets worst for function and type definition. Then when you get into C++, it gets an order of magnitude more complex because almost every code change will somewhat break one or many symbols. This is why there is often "proxies" called PIMPL or d_ptr between the library symbols and the actual implementation code. C++ has no officially standardized way to serialize the object to their symbol names. This is often a pain point and Apple wants to fix this for a decade for has so far failed to get everybody to agree on something.

For embedded devs, more problem arise from the fact that the instruction set and C library themselves are not the same for all devices and this also break pre-compilled code.

Many platform will often favor "static binaries" over dynamic ones to avoid the consequences of breaking the ABI.

I think you see it because there has be a resurgence in interest in C/C++. probably because people are giving up on the idea that all new languages will run on the JVM.

ABI is ancient since it defines the underlying structure that allows you to link compiled object files and liberals together (the latter both statically and dynamically). Allowing code generated in one module to successfully call functions in another.

> Allowing code generated in one module to successfully call functions in another.

That's not quite true. That's already possible without a standard ABI.

What's not possible is to get code compiled by a specific compiler to call modules built by another compiler provided by another vendor. That's the only problem that is addressed by a common ABI.

I would also add that considering MS's interoperability history and how prevalent MSVC++ is, working on a standard ABI would be a waste of time.

> What's not possible is to get code compiled by a specific compiler to call modules built by another compiler provided by another vendor. That's the only problem that is addressed by a common ABI.

Yes, compilers need to agree on the ABI, the platform ABI, that is. Today most platforms already have a de-facto or de-jure standard ABI and compilers have the option to implement it.

Even if such a thing was possible, there is no value in the standard committee standardizing an single ABI as most platforms would never break backward compatibility to switch to it.

No, it is an old term.