There were two fundamentally different proposals for concepts:

Indiana— concepts are records of signatures; checking is done "by signature"; an arbitrary mapping (adapter) can be defined. Notable authors: Doug Gregor, Jeremy Siek, Jaakko Jarvi, a lot of others I'm insulting by forgetting.

Texas— concepts are predicates of "actions" (usage of signatures; expressions). Notable authors: Bjarne Stroustrup, Gaby Dos Reis; later, Andy Sutton.

The crux of the issue is that Doug Gregor actually implemented the Indiana proposal (twice?) and Gaby never implemented the Texas proposal. By 2009, the Indiana proposal was well on track to being accepted; then ... it wasn't.

Fast forward 5 years, and now we've got a re-imagining of the Texas proposal, with no serious dissent, as all the Indiana folks moved on (out of exasperation, frustration; age; interest, whatever).

To be fair, Stroustrup has made an effort to explain his reason for encouraging the Committee to drop the Indiana proposal ( http://www.drdobbs.com/cpp/the-c0x-remove-concepts-decision/... ).

He's also mentioned the Indiana proposal led to increased compile times (as in at least 100% slower) and that the Committee came up with a ridiculous number of concepts for the standard library, which suggested they were looking at things wrong. For instance, there's little value in having CanCompareForEquality, CanCompareForInequality, HasLessThan, HasGreaterThan, HasLessThanOrEqual, and HasGreaterThanOrEqual be separate concepts; they should be grouped into, say, HasTotalOrdering, EqualityComparable, and HasPartialOrdering. The current STL gets this wrong, it wants a concept of HasPartialOrdering but it actually requires HasLessThan (and fakes equality comparison by assuming if a is not less than b and b is not less than a, then a and b must be equal). I don't fault Stepanov for this mistake, it's not obvious and it's relatively easy to tell people "just implement operator< for your types and we'll be able to sort them when needed" instead of "implement the relational operators that make sense; some implementations may use operator< to sort, while others may use operator>, and others operators < and <=, and yet others operators <, !=, and ==, etc."