An ABI can't really be "additive". If you add stuff to an ABI, it's a new ABI. Unless you tweak the definition of ABI to your liking (like introducing new concepts as "module stability").

Let's say you have an iOS application written in Swift 5 and you are using AlamoFire. The original promise of an ABI (like the C ABI, the ObjC ABI, COM, JVM, etc) is that AlamoFire could choose to switch to Swift 6 because of the great new async/await features, and you could still use that binary in your Swift 5 application. Because, you know, there is a stable ABI ;-) If you enhance the ABI, that won't be usually possible. E.g. the Swift 5 program won't understand the "new mangling and calling convention" mentioned in the link. Presumably it could be bridged somehow, or maybe not in a useful way ...

> An ABI can't really be "additive". If you add stuff to an ABI, it's a new ABI.

Not really. You can add new concepts to an ABI without breaking existing code.

Suppose version N+1 of some compiler adds a new language feature, like async/await or whatever. It might involve a new calling convention and symbol mangling for async functions. However non-async functions would not be affected.

Of course if the library author removes old entry points they will break old client apps, but that's not a property of the compiler.

I'm asking because i've read somewhere that async/await was deeply intertwined with try/catch and error handling...

EDIT: well, the link does address this concern, so i suppose everything should be fine..