Versioning solves the sole thing the "Swift 5 ABI" officially claims to solve: Avoiding to embed the Swift libraries in every single binary. If you have apps on your iPhone which use 3 different Swift versions, you would have 3 versioned copies of the runtime in any other environment. Instead those libraries are copied for _every single app_.
Windows is a prime example which uses versioning and still allows to share modules by the means of a proper ABI, COM (__stdcall and friends, yuck).
It is absolutely common to embed multiple C (yes, even C has no stable ABI on Windows!) and C++ runtimes in a single binary and use COM as the ABI.
Something like that would have worked for Swift as well, precisely as demonstrated by the article, using the simpler ObjC runtime as the ABI.
> What does it mean if you have an API passing a struct/class/record around if different libraries have different ideas of what the in memory layout of that struct is
That is precisely what an ABI declares and is used for. In the context of the post, the ABI is the _ObjC_ runtime, which is stable. That potentially different Swift versions being linked have different layouts doesn't matter.
The primary issue with Linux is that it doesn't have explicit support for two level namespaces within dynamic linking. Though it is again also not uncommon to mix ABI-unstable languages like C++ by the means of a stable ABI (either C or for example the ABI defined by Apache).
Windows is a prime example which uses versioning and still allows to share modules by the means of a proper ABI, COM (__stdcall and friends, yuck). It is absolutely common to embed multiple C (yes, even C has no stable ABI on Windows!) and C++ runtimes in a single binary and use COM as the ABI. Something like that would have worked for Swift as well, precisely as demonstrated by the article, using the simpler ObjC runtime as the ABI.
> What does it mean if you have an API passing a struct/class/record around if different libraries have different ideas of what the in memory layout of that struct is
That is precisely what an ABI declares and is used for. In the context of the post, the ABI is the _ObjC_ runtime, which is stable. That potentially different Swift versions being linked have different layouts doesn't matter.
The primary issue with Linux is that it doesn't have explicit support for two level namespaces within dynamic linking. Though it is again also not uncommon to mix ABI-unstable languages like C++ by the means of a stable ABI (either C or for example the ABI defined by Apache).