And if you underspecify, you force the users to invent their own hacks and workarounds, often very poorly. And no, I don't want to "high performance" lock impl

And if you underspecify, you force the users to invent their own hacks and workarounds, often very poorly. And no, I don't want to "high performance" lock implementations that regularly completely deadlock the whole process (deadlocked processes are not very performant) unless wrap every single one of the several hundred uses of them in a test with dubiously-predictable branches, or worse, just completely break the lock invariants (e.g., the lock is now permanently unlocked, even after a lock() on it succeeds) ― it really is not that important how fast you can do the wrong thing.