diff --git a/docs/maintainer/knowledge_base.md b/docs/maintainer/knowledge_base.md
index 25d6b491fc..09c860a785 100644
--- a/docs/maintainer/knowledge_base.md
+++ b/docs/maintainer/knowledge_base.md
@@ -1928,6 +1928,35 @@ os_version:
Finally, note that the `aarch64` and `ppc64le` platforms already use CentOS 7.
+
+
+### Consequences of newer c_stdlib_version
+
+If a library links a newer version of `c_stdlib_version`,
+the _runtime_ requirement on `__glibc` is applied
+but it does not mean downstream dependencies will (or should) be built against the same version.
+The _runtime_ `__glibc` on the build system must still satisfy the exported requirement.
+The default `c_stdlib_version` is `2.17` on linux-64.
+**A dependency on a newer `c_stdlib_version` does not mean dependents must also use that version**.
+However, to build a package with `c_stdlib_version=2.17` that links a library built with `c_stdlib_version=2.28`,
+the linker flag `-Wl,--allow-shlib-undefined` must be specified.
+Without `--allow-shlib-undefined`, you may see errors like:
+
+```
+ld: $PREFIX/lib/libsomething.so: undefined reference to `glob@@GLIBC_2.27'
+```
+
+This flag is in conda-forge's default $LDFLAGS set by the `{{ compiler("c") }}` package,
+so most recipes should not need to be aware that a dependency has updated to newer `c_stdlib_version`.
+If they do, it means $LDFLAGS is not being handled consistently,
+which is probably something feedstock and/or package maintainers should consider fixing.
+
+There is more nuance in runtime compilation in user environments,
+which are also affected by the default version of `sysroot_linux-64` being the old 2.17.
+The `gcc` package does not set environment variables $CC, $LDFLAGS, etc..
+To set these variables on environment activation, install the `c-compiler` package (or `gcc_linux-64` on linux-64),
+or set them by hand in the environment, or avoid the issue by specifying `sysroot_linux-64>=2.28` in the environment.
+