inherit from STL container

You're well informed, I have to say;) All STL containers were designed according to the object-based paradigm (a la Ada 83) which differs from commonplace object-oriented design. The main difference between the two is that the former doesn't use inheritance in any way. Instead, each class is a self-sufficient entity that doesn't have virtual functions, protected members or base classes. The motive for this design is performance, and prior experience with a similar library in Ada (STL was first implemented in 1993 I believe at HP)
The downside is that you can't safely derive new classes from STL containers. The first problem you'll face is that you can't override any member functions since none of them is virtual. You will also have difficulties with tweaking the implementation of containers since all their data members are private (as they should be), but there are no helper functions that are protected. Finally, there's the problem of non-virtual destructors which could lead to memory leaks.
Some workarounds exist but they're troublesome and not really worth the risk and bother. Instead, you can create your own container by using an STL container as a data member and delegate many of your container operations to the STL container's operations. In fact, STL uses this approach stack for example, which is implemented by means of another STL container. I know this isn't exactly what you wanted to hear but it's best to know the precise state of affairs before making any design decisions.
As for C++09: there are no proposals for adding virtual destructors to STL containers at the moment. I know there have been quite a few requests of this kind but adding virtual destructors would break existing code in some areas, add more space to each container and add some runtime overhead. This overhead isn't always optional so it's a bad idea to impose it on every C++ program that uses STL. It's worth noting that there are many other requests for modifying STL containers. For example, adding volatile member functions (at present, there are only const member functions). Another, perhpas the most popular request, is adding thread safety, whatever that means.

If you add a virtual destructor, you change the binary layout of STL containers. So if you have an array of container objects or you're using pointer arithmetic with the assumption about a certain size per object, such code would break. You and I wouldn't write such code normally, but it exists. There are other examples which relate to pointers to members. In some compilers, the representation of pointers to members has three versions, depending on the class type. If a class changes from non-polymorphic to polymorphic, the underlying representation of pointers to members (as well as the "addresses" of members) will change. Again, with through and through design and encapsulation, all it would take is recompilation but sometimes recompilation is impossible. Think also about framneworks that serialize objects. If a string object is serialized and then deserialized, the code that takes care of these operations that must know that the class has an extra member, i.e. the vptr. Changing such code isn't a trivial task.