> We consider it a non-goal to support legacy code for which the source code is no longer available
is such a pejorative way to talk about ABI stability.
Yes, supporting code you lost the source for is one use case for ABI compatibility. I guess it’s a real need that some people have. But it’s by far the most unsympathetic use case. It reeks of antiquated development practices. Plus, binaries with lost source are inherently a ticking time bomb since you won’t be able to port the code to new platforms or make any fixes.
But what about all the other use cases for ABI stability?
What if your vendor has the source code but doesn’t want to give it to you?
What if you do have the source, but you want to be able to update libraries without rebuilding every executable that depends on them? Especially valuable if you’re building an operating system, Linux or otherwise. (There’s a reason that Swift spent so much effort on ABI compatibility.)
What if you want to let people build dynamically-loadable plugins? (This one at least gets a brief mention in the Carbon goals document, albeit under the "legacy compiled libraries" section.)
What if you just want to save build time via pre-built libraries?
Don't get me wrong, I'm not against Carbon's decision to make ABI stability a non-goal. There are real tradeoffs in making ABI stability work. I'm just saying, if you're going to explain why you don't support it, don't dismiss the use cases for it by picking such a poor exemplar.