My understanding of the STL issues with games is a two-fold issue: STL classes are a mess of templates and virtual functions (which tends to introduce overhead), and STL containers are generally built to just work without sweating the details (which leads to inefficiently managed memory for objects)
The first issue is, as far as I can tell, endemic to any library trying to be general-purpose, but also something compilers can deal with. I don't know how much STL implementations use constexpr (new in C++14), but I wouldn't be surprised if they were trying to get as many function calls and template instantiations folded down to minimize overhead as possible, once the compiler is through with it.
The second issue, on the other hand, is indeed a design issue with STL. For applications that deal with large chunks of relatively unchanging data, they are fine. For applications that deal with data that's constantly changing in small chunks (like games) the overhead of constantly constructing and destroying objects, as well as the overhead when classes like vector<> need to expand, leaves a lot to be desired for performance. Linked list or map structures avoid that allocation issue, but have terrible cache performance, which is huge for optimization these days. On this, I don't know of any specific efforts to clean anything up, but I am aware of some research effort into containers that allow for dynamic allocation while minimizing destruction and allocation overhead, but nothing that seems likely to make it into STL for several years. Colonies
are an example of this research.
There's also the whole SG14 working group
, which is all about making standard C++ better for games development.