In this scenario, I'll have to choose which libc I want to run. These won't be portable Linux binaries in the true sense of the word; I'll have to leave Alpine out, and possibly Android, which I don't want.

You don't strictly need to; you can write freestanding C, and use the Linux kernel directly.

Fair point - while it's certainly possible to make a decision per individual library elsewhere, libc is the one thing that really will need to be linked dynamically for glibc, and it'll freeze a minimum version into the binary (i.e. it should be built against an old version of glibc).

I don't think Android is a target in most cases of this, so this would boil down to shipping 2* binaries, one glibc and one musl.

I'd need to check how musl behaves for compatibility, I'm assuming it'll be a minimum like glibc.

All of this said - you'll need to ship multiple binaries anyway, these days: x86_64 + aarch64. Possibly more…

Can you really mix it? When I break or remove a shared lib, some binaries no longer work. With static libs or even better, e. g. statically compiled busybox, I don't have that issue, so I disagree on the claim that mixing solves everything as such. I keep the basic toolchain I use as statically compiled variant. The whole system works better if I can break it less easily.

I'm not sure that's particularly relevant; if I null out bits of the statically linked binary to remove some code paths, they break too.