You only need to build against the oldest glibc version you want to support - and the runtime does nothing to change that since you can't bunle your own libc (if you want any dynamic linking at all, which you need fro e.g. OpenGL/Vulkan).

> Y versions of sound libraries

The steam runtime makes sure that there is a libasount/libpulse* present so that your program can start if it links against those, but it does not provide anything for compatibility between them - that can be achieved by e.g. SDL or OpenAL Soft (which load them dynamically which means there is no problem if the libraries are missing and you won't even need the runtime). It's also ok to only support one audio system then then have users figure out the compatibility on their system (e.g. PipeWire supports the ALSA and Pulse ABIs).

> Z versions of graphic APIs

Same, the runtime ensures that a vulkan loader is present but does not actually do anything for compatibility. Both OpenGL and Vulkan also provide backwards compatiblity so you again just need to decide on a minimum version.

What the steam runtime mainly does is provide a bunch of libraries that are present on Ubuntu that games might link against so that everyone has them. Nothing stopping the games from shipping those libraries themselves though.

Yes, the only difference (between backported bugfixes) really is which glibc version is included.

This does not apply to other libc implementations like musl which only tend to be used in lightweight focused distros intended for embedded systems or containers like Alpine Linux. With these even the steam runtime won't help you since it (and Steam) also requires glibc and it's needed to use e.g. flatpak to provide a glibc userland - that's on the user/distro though: https://wiki.alpinelinux.org/wiki/Steam

> or libraries in general

Libraries generally fall into two categories: system libraries required to interface with hardware or other OS components and general user libraries. System libraries (e.g. libasound, libpulse*, libGL, libvulkan, libX11, libwayland) do provide a stable ABI with strong backwards compatibility and you can and should rely on the system verisions (again, decide on a minimum version, e.g. by compiling on Ubuntu LTS or something or use SDL to abstract this for your). Don't include copies of these unless you know what you are doing.

Other libraries (for example zlib, libpng, ...) do not generally provide any ABI guarantees (at least not long enough ones to matter for binary distribution) so you should ship your own copies or use the steam runtime to do that for your. If you can, statically link them into your binary and hide the symbols so that they don't clash with any system libraries that may be loaded - this provides the best future compatiblity with current and future distros.

There are some interface/abstraction libraries like SDL and OpenAl soft that both provide a stable ABI and themselves build on other stable ABIs. Here the best path is to distribute your own copies but do not statically link them.

A pain point is the C++ standard library libstdc++. Like glibc it currently provides a stable ABI with backwards compatibility. Unlike glibc it tends to be much closer linked to the compiler version so it will be harder to avoid requiring a newer version than what your oldest target distro comes with, unless you are fine with restricting yourself to an older compiler and C++ version. It might be tempting to include your own copy but this will cause problems because graphics Mesa (the open-source Vulkan and OpenGL implementation) also uses libstdc++ and requires a copy at least as new as the one it was built with - which any copy you bundle won't be for long. If you can statically link libstdc++ and libgcc (and all your C++ dependencies) and hide all C++ symbols then you are fine. Otherwise, rely on the steam runtime to get your a new enough version.*