This version is a draft, for discussion.

• Versioning allows the library to avoid changing the SONAME when the API changes and instead compatibility functions can be written to provide backwards compatibility for older applications.
• Versioned symbols provide the information required to ensure that libraries are actually new enough to run the software that links to them.

I think the new text is misleading. There are other mechanisms to decide whether libraries are "new enough", in particular SONAME traditionally is used for that. The old text is better, even though it concentrates on one aspect of symbol versioning that is important to glibc but not to most other packages.

What about this:

When versioning is not used and the API changes, the library must change the SONAME so that we know that programs linked to it are not compatible anymore and must be rebuilt. (The API changes when symbols are added, removed, or their signature changes.) With versioning, when a program is linked to a library and uses a specific set of versioned symbols, we specify requirements on those versions only. This gives as much more precise information whether the binary program is compatible with older or newer versions of the library. If the library authors are careful to ever only add symbols, programs linked against older versions of the library never need to be rebuilt. But even if the symbols are changed, with versioning, the library can provide compatibility versions of older symbols, maintaining strict backwards compatibility forever.

And here insert example of a library that just adds symbols, e.g. libsystemd, relatively simple, and a second example of a complex library like glibc that has multiple versions of symbols.

Further wordsmithing would be good…

There are other mechanisms to decide whether libraries are "new enough", in particular SONAME traditionally is used for that

That's true, but that's the bug that needs to be fixed: SONAME is inadequate to the purpose.

Compatibility between an application and shared libraries has both a lower and an upper boundary: the version that introduced the newest feature the application needs, and some future version where compatibility has been broken.

SONAME provides only the semantic major version of a library interface, suggesting that ".0.0" is the lower boundary and ".0.0" (an SONAME bump) is the upper boundary. The implied lower boundary is virtually always wrong. Symbol versioning provides supplementary information that provides a more accurate lower boundary.

When versioning is not used and the API changes, the library must change the SONAME ... The API changes when symbols are added

Similarly, the term "change" is insufficient for this purpose. We must separate API changes into two categories: compatible changes and breaking changes.

A library will only change its SONAME when it introduces breaking changes. We don't want to tell developers to change the SONAME when the API "changes".

Look at it this way: Adding features to a library is (generally) a compatible change. Removing features is a breaking change. If we imagine a timeline for a library's lifecycle, the major version does not change as the software moves forward and adds features. But we know that it must change if/when features are removed in order to communicate that compatibility could be broken, if applications used the features that were removed. If a user downgrades a library relative to what was in the build root when an application was built, they have effectively removed features. They've moved the library backward on its timeline. That is a breaking change that can't be communicated by the SONAME, because that didn't change as the library moved forward on its timeline.

I think libsystemd is a good example of why symbol versioning is an important focus. Adding symbols is an ABI break, just only a backward one. But without a symbol version map, that information is not conveyed in a reasonable fashion. That's why libsystemd has one, after all.

Examples for automake, cmake, and meson have been added. Changes have been reviewed with asciidoctor.

I'm still interested in feedback and suggestions, but I've removed "DRAFT" from the title.

This looks pretty good to me at a first glance. +1