Glibc is in the unfortunate position that it gets asked to solve all the hard parts the kernel guys don't want to solve, but also it gets asked to solve a lot of hard parts that application guys do not want to solve. In many ways, it's the layer in the system where all the ugly stuff ends up going that nobody else wants to deal with.
Combine that with an absolute requirement of binary compatibility, and frankly, I appreciate greatly a set of glibc maintainers who are on the conservative side. Any new API is going to be there forever, unchangable.
That doesn't mean that progress should not be possible, and it doesn't mean that the atmosphere shouldn't be open and pleasant, but in many ways, the glibc guys and the kernel filesystem guys need to share a mindset of being extremely careful and conservative.... not one of doing wild things just because you can.
the debate about strcpy/strncpy/strlcpy is one of those messy ones. on first sight, strlcpy is an obvious right answer. however, when you look deeper at it, it's not true.... strlcpy can in fact be more dangerous. strcpy_c and co are actually better ideas, and glibc's strcpy() has a built in "abort if we know we're overflowing" logic that works together with gcc to detect many of the more simple buffer overflow case. (and it *aborts*, it does not silently continue with what is effectively corrupted data).
If Ulrich and co had added strlcpy early on, we'd now be wondering how such a stupid decision could have been made because it now has to be deprecated ;-(