Problems With STL: What Drove Me To Create Something Else

There is nothing inherently wrong with STL! It's a very robust and heavily tested solution that proved itself to be a good companion to programmer needs, BUT there is nothing ultimate about it. It's just one IMPLEMENTATION of "data structure & algorithms" concepts, not perfect like everything else in life, with its own qualities and defects.

What I loved about STL

Its iterators. STL iterators are without doubt more advanced/complete than anything done on that topic at least in languages I know: Java or PHP. Clearly a LOT of effort has been put to make them as flexible as they are, with the unfortunate side effect of becoming fiendishly complicated to employ for a non-STL list.

What I failed to love about STL

It's disorderly. What I liked about Collections API in Java is the interface-implementation paradigm that suits data structures the best. In C++ as well, a list should be a concept (class with pure virtual methods), while a dynamic array / linked list / doubly linked list should be different implementations of same concept. Not only should programmer abstract the list implementation by using List* only (which is a no-cost operation), but he will be assured whatever functionality is defined by List will have an implementation for whatever list type he uses (eg: linked list). In STL, because data structures are not designed hierarchically, there is an absolute chaos in method names (who aren't very intuitive BTW) and functionality (which may or may not have been implemented) so one needs to constantly check documentation.
It's coupled. It's extremely difficult to glue its components (be it iterators or dependency classes/structs) with non-STL components. It's clear that the very good programmers who have worked for it, even though they went overboard with decoupling to largest extent imaginable (which is why STL structures' implementations are so complex), the end result has been something so complicated that it becomes uninviting to understand (leaving the impression of overprogrammed code).
Performance of HashTable implementations (unorderedmap, unorderedset @ C++11), inferior to others I've tested
Design decisions (for example, stacks and queues expose too much functionality when theory requires them to only include two functionalities: push/pop(/peek), enqueue/dequeue)

What I missed in STL

LinkedHashTable (and its LinkedHashMap, LinkedHashSet implementations): this is a hashtable where entries are iterated by insertion order (by adding doubly-linked-list behavior to hash table nodes). Actually, in languages such as PHP or Python that's the only HashTable known. While coding in C++, I frequently missed this option, which actually adds less than 10% performance taxation.
Trees & Graphs. For some reason there is no "official" implementation in any language I know of, even though they are both routinely needed and can be abstracted with not much of an effort.

Conclusions

Clearly STL did not fully fit what I wanted: something complete & beautiful, standing on natural unbreakable order and coded on principles of simplicity and elegance. Therefore, I decided to reinvent the wheel and build something more beautiful instead!