Howard Hinnant:
Just to be clear, I'm extremely well positioned to know that vendors are not evil, and are not adversaries.
For the record, I applied "non-evil" to the runtime checks done in a release build, not to a vendor. :-)
They are people, just like you and me. And when the standard gives them choices, they must make them. They try to make them in such a way as to please most of their customers. Sometimes they choose correctly, and sometimes they do not (as a vendor I admit to having chosen incorrectly sometimes). No vendor that I'm aware of is immune to making incorrect choices.
I accept that. So what's the problem? Vendor A ignores the mutex argument, his users complain, so he finds a way to add checking that doesn't increase sizeof(condition) and doesn't compromise performance for the rest of the user base. Vendor B stores the mutex pointer in std::condition, his users complain, he waits for the next ABI breakage and finds a way to achieve comparable checking quality and efficiency without increasing sizeof(condition). Everyone is happy. ...
I don't know any more than you do, so my "forward looking" is no more or less valid than yours. But I strongly believe that it would be careless of us to be careless with sizeof(std::condition).
I'm not being careless with sizeof(condition). I already demonstrated two ways to achieve checking without storing the pointer into the condition itself, and hinted at another possibility (exploiting an unused void* in pthread_cond_t). I also questioned your assertion that increasing sizeof(condition) from 28 to 32 is of practical importance.