There are distros (like Alpine) that link everything against musl, and provide a separate library (gcompat) for glibc-specific stuff. Alpine is crazy popular in the "lightweight containers" world, because of the small download sizes, so musl is actually getting a lot of real-world testing.
Go has demonstrated that "mostly-static" linking is a viable alternative to the orthodox choices of "fully static" or "fully dynamic"; for example, they link to libsystem on macOS, libc on OpenBSD, or sometimes to the "real" libc on other unices (to be able to use getaddrinfo, which might do more than just look at /etc/resolv.conf).
That approach wasn't without issues, including security holes - there were instances of bugs where the only solution was: "rebuild every Go executable with a newer toolchain". But I think this approach is under-explored: distributing "fat" binaries that bundle musl libc, libpng42, libfoo666, libquux1337, but e.g. dynamically link to things like Mesa.
Except that they didn't had to prove a point, the old timers remember when static linking was the only option and dynamic linking was seen as very welcome solution over hacks like overlay sections.
However we just don't get rid of static linking and decided to go back into 1980's UNIX, because there are use cases where dynamic linking is actually usefull, and achieving the same via OS IPC is too resource demanding.
There is though a fine balance between offering such kind of features via dynamic code loading and OS IPC, because host stability and security exploits also are a relevant point of interest in modern computing.
> [...] there are use cases where dynamic linking is actually usefull, and achieving the same via OS IPC is too resource demanding.
Exactly my point with Mesa, it would be a huge mess to try to statically link it into your game, and it gets even funnier with each newly released GPU / driver update.
Go has demonstrated that "mostly-static" linking is a viable alternative to the orthodox choices of "fully static" or "fully dynamic"; for example, they link to libsystem on macOS, libc on OpenBSD, or sometimes to the "real" libc on other unices (to be able to use getaddrinfo, which might do more than just look at /etc/resolv.conf).
That approach wasn't without issues, including security holes - there were instances of bugs where the only solution was: "rebuild every Go executable with a newer toolchain". But I think this approach is under-explored: distributing "fat" binaries that bundle musl libc, libpng42, libfoo666, libquux1337, but e.g. dynamically link to things like Mesa.