Another reason to prefer `new`/`delete` over `[std::]malloc`/`[std::]free` (and `std::vector` over `[std::]realloc`) is that `malloc`/`realloc`/`free` don't call constructors and destructors, which means using them with non-POD types is UB (more concretely, you'll get bugs if the constructors or destructors manage some resource like a mutex, heap allocation or file handle).

As for outdated stuff in the standard library, that's something that affects every language as it ages. `map`/`set` aren't, IMO, the worst offenders; they were misleadingly-named (like `std::endl` and `std::move`), but RB-trees are a useful data structure, and while they are slower than hash tables (`unordered_map`/`unordered_set`) for the typical map/set use case, it's not like they're buggy.

The one that IMO most cries out for replacement is `[std::]rand` (inherited from the C standard library), whose RNG is abysmally low quality/predictable, very slow, and thread-unsafe. C++11 did introduce a new RNG API[1], but it's quite cumbersome and verbose to use, when they really need to introduce a simple API like BSD/Mac `arc4random_uniform`[2] so people will stop using `rand`.

Edit: I see that this is being addressed, although it didn't make it into C++17.[3]

While not buggy, iostreams are also getting a bit long in the tooth and could stand to be replaced with a more modern API, the iterator APIs (in the <algorithm> and <numeric> headers, etc) should also be methods on STL types, and `std::string` isn't quite deprecation-worthy, but it would be nice if the STL were augmented with a state-of-the-art encoding-aware string implementation like Swift's. And it would be nice if the STL acknowledged the existence of the internet (with high-level libcurl-like functionality in addition to the very low-level Networking TS).

[1] http://en.cppreference.com/w/cpp/numeric/random

[2] https://www.unix.com/man-page/freebsd/3/arc4random_uniform

[3] http://en.cppreference.com/w/cpp/experimental/randint