Maybe it's clearer if I say 'system libc' rather than 'glibc'. For example, I can apt-get a package to get libpython2.7.a (compiled with 'system libc'). This can then be statically linked, assuming rust supports statically linking 'system libc'. But if rust only supports statically linking a 'non system libc', I am forced to recompile my libs if there are incompatibilities between 'system libc' and 'non system libc'. True, it doesn't help with libraries that are just nontrivial to statically link in general. But it does help with a number of common cases. I now realise this also relates to what @gkoz was saying - regardless of what the 'system libc' actually is, it'd be nice to support static linking with it. My glibc obsession is just an side-effect of me working on Ubuntu.
Sure! Where? I could start a page in the rust book (under nightly?) talking about static binaries, or a 'going off-piste' in cargo? Do you have an 'experimental stuff' area anywhere? A gist/github repo is also possible...but I'm not so fond because I really do think there are going to be people wanting to do this and official docs stand some chance of being updated as musl (at least) moves along.