If I'm understanding this article correctly, the basic proposal is that if you enable symbol aliasing, you can enable ABI breakages without any pain whatsoever. However, they seem to be ignoring one very important issue with ABI breakages: libraries tend to pass types around.
The actual most painful part of ABI breakage is if you have, say, library A that's compiled against old-ABI and library B that's compiled against new-ABI and library A passes ABI-varying types to library B. Like, say, std::string (which changed ABI as a result of C++11). gcc managed to make it work--but the process was so painful (and required adding new features to C++ to do so!), that they have said that they do not want to have to ever do that again.
It's relatively easy to completely change the functionality of a library function and use this sort of magic to always select the right function. But when you broach changing something like intmax_t and time_t, you have to be cognizant that the issue is different libraries (neither of whom are the standard library) who aren't prepared for the type to be different communicating with the same type.
The author then argues that it is at least a step forward:
> For those of us in large ecosystems who have to write plugins or play nice with other applications and system libraries, we’re generally the last to get the benefits. But, at least we’ll finally have the chance to have that discussion with our communities, rather than just being outright denied the opportunity before Day 0.
The actual most painful part of ABI breakage is if you have, say, library A that's compiled against old-ABI and library B that's compiled against new-ABI and library A passes ABI-varying types to library B. Like, say, std::string (which changed ABI as a result of C++11). gcc managed to make it work--but the process was so painful (and required adding new features to C++ to do so!), that they have said that they do not want to have to ever do that again.
It's relatively easy to completely change the functionality of a library function and use this sort of magic to always select the right function. But when you broach changing something like intmax_t and time_t, you have to be cognizant that the issue is different libraries (neither of whom are the standard library) who aren't prepared for the type to be different communicating with the same type.