You are barking up the wrong tree. The ABI compatibility is never expected nor is taken for granted, for it is an internal implementation aspect of an operatin

You are barking up the wrong tree. The ABI compatibility is never expected nor is taken for granted, for it is an internal implementation aspect of an operating system. An ISA does not equate to an ABI either. Blaming Apple for devising or augmenting an aarch64 ABI is akin to blaming IBM for using the XCOFF and the AIX ABI on their POWER platforms rather than using the SysV ELF ABI on the same POWER platform that Linux is a signatory to. Incompatible ABI's used to be a common place across different UNIX flavours from different vendor running on the same ISA. DEC Ultrix running on MIPS used an ABI distinct from that of SGI Irix running on the same MIPS ISA. For many years the ABI was not even recognised as a thing and was rather very loosely based on the original PDP-11 ABI (e.g. the result is either in the zeroeth register of the CPU however it was actully named, or on the stack if the result was too big to fit in, input parameters either in the first 4-5 registers or on the stack etc). It took years of bickering amongst UNIX vendors until the SysV ELF ABI was finaliased and adopted across all modern UNIX implementations (sans Mach-O on Darwin and XCOFF on AIX). Linux went all in with the ELF ABI as it was well positioned to get away from a zoo of legacy ABI's it historically had to support on different hardware plaftorms (a.out, COFF, ECOFF and whatever else there was out there) even at the cost of the performance loss on the 32-bit x86. Whereas all BSD's (Free, Net and Open) just baulked at it and stuck with the historical BSD ABI for several more years to renege later on.