Any time you compile a C program on Fedora 15, the resulting binary is marked as being suitable only for Linux 2.6.32 and above (running 'file' shows this information). It appears that this marking comes from the same marking on /lib/libc-2.14.so and its friends - libraries from other packages do not carry this marking. This is not a problem for dynamically-linked binaries, because if you copy the binary to, say, and old system, it will dynamically-link the system's older glibc, and it will work (apparently the loader ignores the "for Linux 2.6.32" marking on the binary itself). But it becomes a BIG portability problem for statically compiled binaries: The typical use for static compilation (-static option to ld or gcc) is to create a self-contained binary which will run on a wide variety of systems (with Linux and the same hardware architecture, of course). The marking "Linux 2.6.32" on glibc ruins this feature: If you try to to run a binary statically-compiled on Fedora 15 in a 2-year-old system (Linux 2.6.32 came out only in the beginning of 2010), it will immediately stop with an error message about having an old kernel. As it stands, it means that if I want to statically-compile programs and know that people can run the result on a as-wide-as-possible range of systems, I cannot do this compilation on Fedora 15. I don't think it should be this way.
The 2.6.32+ limitation is there because Fedora 15 glibc is configured to optimize away support for older kernels, which speeds it up. If you think that -static linked binaries are self-contained, you're wrong, whenever a statically linked binary uses localization, or getaddrinfo/gethostbyname/whatever other function needs nss etc., it needs to dlopen libraries and then it is much more system dependent than dynamically linked binary. See http://www.akkadia.org/drepper/no_static_linking.html for more information. If you want binaries that you can run on older systems, just compile/link them (preferrably dynamically) on the oldest system you want to support.
It makes little sense (at least for me) to, on one hand, have a package glibc-static-2.14-5.x86_64, and on the other hand point people who have questions about it to a web page page about static linking being evil. If you think it is evil, perhaps the package should be dropped altogether? In any case, I'm well aware of the *potential* portability problems even with static linking. But in many practical cases, it sort-of works, and this is why people want to have the static linking option (can you think of another reason?).