There's no need for that, though: glibc already *contains* code which looks at the
capabiliities of your machine and uses different syscall mechanisms depending on that (int80
versus vsyscall on x86/x86-64, for instance).
Should we run out of syscalls (on x86-64, we only have 2^32 minus a couple of hundred left!
such a harsh limit!) or should we decide the syscall table is too damn huge, then we could
always introduce another syscall mechanism and call it unconditionally from a new glibc.
The point being, if you can hack ld.so to preload things automatically, you can just as easily
modify libc.so to do the job itself in a much less ugly fashion :)
(of course the problem here remains the breaking of compatibility with all older glibcs: the
newer glibc doesn't need a major version bump, though. I suspect this is a step which the
kernel hackers will be very reluctant to take. It's happened on some arches, but they're all
relatively minor ones.)