Concepts: http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29
Modules: http://clang.llvm.org/docs/Modules.html
Coroutines: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n370...
operator. (for proxies): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n417...
Uniform call syntax: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n417...
Source code (implemented with a lot of help from C macros): https://github.com/snaewe/typeswitch
http://lambda-the-ultimate.org/node/3518 (voted off) http://lambda-the-ultimate.org/node/4450 (suggestions for future work)
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).
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."
Here's numbers for the ones you listed:
Concepts: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n436...
Modules: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n446...
Coroutines: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n439... & http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n439.... Also http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n413...
operator dot: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n447...
Uniform call syntax: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n447...
Here are some others that Stroustrup listed. I think they're probably important proposals. I imagine Stroustrup has at least some priority order in his list.
Ranges: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n438...
Comparisons: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n447... & http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n447...
array_view: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n434...
I only ever remember hearing of one programming language supporting it, and I can't even remember what it is. Maybe it was Nim?