Glibc is fantastically stable and backwards compatible in all the same ways , and I think you're overstating how backwards compatible windows is as well. Microsoft has the exact same dynamic library issues that Linux does via it's Microsoft Visual C++ distrubutables (as one example). Likewise, there's forwards compatibility issues on Windows as well (if you build a program in Windows 11 you'll have a hard time running that on windows XP/Vista for a huge number of reasons).
If you build a statically linked program with only glibc dynamically linked, and you do that on Linux from 2005,then that program should run exactly the same today on Linux. The same is true for Windows software.
Im pretty sure it’s safe to distribute Windows 11 built binaries to windows 7 and windows 10 if it’s a valid target set in Visual Studio. The c++ runtime is its own thing because of a combination of c++ BS (no stable runtime) and c++ isn’t an official part of Windows. It’s a developer tool they offer. But you can statically link the c++ runtime in which case you can build with the latest runtime on Windows 11 and distribute to an older Windows.
Linux is the only space where you have to literally do your build on an old snapshot of a distro with an old glibc so that you can distribute said software. If you’re in c++ land you’re in for a world of hurt because the version of the language is now constrained to whatever was available at the time that old distro from 5+ years ago snapshotted unless you build a newer compiler yourself from scratch. With Rust at least this is much easier since they build their toolchain on an old version of Linux and thus their binaries are similarly easily distributed and the latest Rust compiler is trivially easy to obtain on old Linux distros.
Source: I’m literally doing this today for my day job
You can also build a cross-compiler to target an older glibc, you are not limited to the distro-provided toolchain. This also allows to to use newer C++ features (with exceptions) as those mostly depend on the GCC version and not glibc version. Of course the supported range of glibc version varies with gcc version, just like visual studio doesn't support XP anymore - the difference is that if you are sufficiently motivated you can patch gcc.
If you build a statically linked program with only glibc dynamically linked, and you do that on Linux from 2005,then that program should run exactly the same today on Linux. The same is true for Windows software.