I think it would be more productive to have a "Linux glibc liason".
A proactive person which would:
1. Maintain a fast-merge branch of glibc for new Linux functionality
(probably by topic);
2. Pester the hell out of any kernel developer that does not ALSO
work in that fast-merge branch code to integrate the new functionality
in glibc. Anyone proposing a syscall would have to ALSO provide
userspace code to use it (which also ensures the thing is properly
tested and usable);
3. Work with glibc to merge the fast-merge topic branches as soon as
practical (i.e. after it is working well, and stable enough to become
ABI in practice), but respecting the glibc release schedule.
That liason needs to be someone with "very good taste" for ABI and
syscall design, plus whatever key skills are needed in the glibc side.
And people could use the fast-merge branches to widely test the new
functionality, and even do early deployments where required.