is there precedence for linux adding new APIs which wrap old APIs, don't implement some features of the old APIs, and add their own new functionality on top?
It seems like a recipe for disaster, but also maybe it's the only realistic way you can go to maintain backwards compatibility.
I'm sure why it's a "recipe for disaster"? The old API is very crufty and now that the problem is stable and well understood, the kernel developers would prefer to start with a cleaner API. Not least because adding (eg) NUMA support to the existing API would be piling hacks on hacks. Take a look at the old API and wonder where you would pass the NUMA struct pointer:
Another special feature of futexes is that no one ever used them directly (not least because they are subtle to use correctly). Instead a few libraries used them and implemented standard APIs on top (pthread etc). Libraries like glibc and other libcs, and probably a few languages that have an aversion to using glibc. So the specific use cases of the old API are well known and scoped.
> probably a few languages that have an aversion to using glibc.
You don't need an aversion to the whole glibc to consider that "Just eat some archaic data structure" is too expensive for a language that cares about performance.
Rust's Mutex is defined over futex on Linux and some other Unix systems, srw locks on Windows because if you write it in terms of the pthread structure or the equivalent for Windows it's slower and much bigger.
It seems like a recipe for disaster, but also maybe it's the only realistic way you can go to maintain backwards compatibility.