I meant the comment you responded to for a different thread, but yes, there is a strong mapping between the kernel of an OS and the preferred C library of that OS, because what is the point of exposing functionality to programs in userspace, like more efficient methods, if you have to crack open kernel docs to figure out how to use it, instead of a nice wrapper in your C library. And both the kernel people and the clib people want you to have access to better methods.

But as their goals and timelines are different, they are out sync, which comes into play not only in the new functionality not being included, but variations of existing functionality where the function has additional flags or parameters that the clib function hasn't added. For example, you'll often see this in areas involving threading, starting processes, and sockets. Luckily for most people you'll often find a fork of the clib or just a 3rd party library that wraps the functionality, but if you are on cutting edge or using a feature that never really caught on because its applicability is very niche, you'll have to go back to syscalls.