This is a bad idea. It amounts to creating a fork of glibc that will forever cause compatibility problems. It would expand the responsibility of the kernel maintainers to also include the maintenance of what is essentially not kernel code. They have enough to do already.
What problem are you trying to solve? glibc developers are not accepting changes to the API fast enough? They shouldn't allow the core interfaces for Linux applications to change quickly or easily as that would undermine the stability of the Linux environment and the confidence of the users. Why is it important for some particular function to be added to the c library? It is not that difficult to build a library for Linux and install it.
One of the main problems with glibc now is its size. For some embedded projects, glibc is just too big already. This issue is addressed by using reduced glibc alternatives or custom modifications of glibc itself. Neither solution is entirely satisfactory.
What is needed is to concentrate of sound engineering principals; particularly the one that Microsoft has never learned. That reliability and maintainability requires that things be kept as simple as practical. Do not add to the kernel developers the responsibility for the user space libc. The glibc maintainers have been doing an adequate job while not chasing every fad that comes along.
When Microsoft extends its operating system with Office code and Outlook code, it compromises reliability and security. Microsoft does not do this for any good engineering reason, they do it for a business reason. They do it to control the market.
The reasons for not combining libc with the kernel far out weigh the benefits. Please do not do this.