Rule no. 1 for system changes:
If it ain’t broken, don’t fix it.
If the custom containers work just fine and impose no performance/memory downside, there’s no reason to switch to STL ones. Obviously, this can be tested and it seems some did that already (and seemingly there’s no reason to switch).
Auto… oh, auto… Let’s not. Please. I like to read my code and understand it without having to move back through functions until a real type appears somewhere.
I see the point in using it for abbreviation purposes, though. Iterators are a good example, because their type declaration usually looks like it was made to make people suffer. If there is a “auto iter = someContainer.begin();”, everybody will understand it and some (like me) will be thankful. A typedef is IMO not a solution here because it just moves the problem out of sight (you got the ugly piece of code elsewhere, but it is still present).
But in all other cases, auto just adds confusion instead of clarity.
Either way, there is no gain in replacing working existing code with it.
I can’t say much about other issues like with variadic templates. Personally, I avoid templates like the plague, because I like to retain my sanity when reading error outputs. Of course, I see the point in them, so if existing code can actually be made more readable or more performant with them, I’m all for it.
As long as I don’t have to write them, I really don’t care if a library I use makes use of them