The efficiency of std::condition_variable is of course platform-dependent, because it depends on the synchronization primitives provided by the OS and hardware. But this change seems to replace one vague, imprecise statement with another.

I'm mildly in favor of this change, because we usually talk about "implementation" in the C++ standard when we mean anything related to the compiler or OS platform. For example, [fs.conform.9945] consistently talks about "implementations", encompassing both the C++ library and the OS platform. I'm lukewarm about the "maximum" -> "better" change, although relative statements (as opposed to absolute ones) seem more appropriate for a standard document.

Yes, it looks like all the other uses of "platform" are at least in Notes (and although this preamble is only semi-normative, it's not actually in a Note).

With this PR I wanted to start off some discussion about the issue.
I should clear up that "better efficiency" in this case looks to be relative to std::condition_variable_any.
Maybe instead of std::condition_variable being faster it should be said that std::condition_variable_any can be slower?

Well the spec of std::condition_variable is intended to allow the implementation to achieve maximum performance for a condition variable that supports waiting and notifying, i.e. it shouldn't add any abstraction penalty to the underlying OS primitives. If the implementation fails to achieve maximum performance, that's not the spec's fault 😄

std::condition_variable_any does add additional abstraction, by supporting user-defined locks, and so generally won't be as fast as the OS primitives.

If we're going to change this, I'd also suggest changing "some implementations", as that is meaningless. Which ones? Does it tell a user whether their implementation gets maximum performance?

How about:

Class condition_variable provides a condition variable that can only wait on an object of type unique_lock<mutex>, allowing the implementation to be more efficient. Class condition_variable_any provides a general condition variable that can wait on objects of user-supplied lock types.

@jwakely, sounds good to me.

Yep, that sounds much better.