The system calls are documented and backward compatible. However, Glib-C is only forward compatible, but not forward compatible. An application, built linking against an older version of Glibc than the one found at the deployment machine, is pretty likely to work on this machine, whereas the other way around will result on a linking error.

By using MUSL it is possible to build fully statically linked applications that works everywhere, however dlopen(), dlclose() calls, that are used for loading shared libraries and plugin at runtime on Unix-like systems, do not work with MUSL.

Glibc is LGPL, which makes some exceptions for system libraries, which glibc would fall under. It's been a while since I've read it and IANAL, so I'm not sure what exactly would be allowed.

The bigger problem is that glibc cannot be statically linked properly. It dlopen's some libraries, like for NSS. Maybe games could avoid triggering those cases but musl is definitely better.

While syscalls themselves are backward-compatible (even for faulty behavior), I think I've read somewhere that some parts of DRI are not, but I've lost the source on that.

The bigger problem is that for games you will to interface with OpenGL/Vulkan and probalbly Pulse/ALSA and those are all shared libraries which you cannot use from a completely static executable.