for memory remapping hacks to be worthwhile, the vector needs to be huge, so I doubt it is often enough a win to be suitable for a general purpose library.
The reason for realloc is that often an allocator can extend an existing allocation in place if the next block is free (and this can be done without syscalls). As you described, except for trivially copyable objects though, realloc doesn't really work in C++, so a better allocator interface for C++ would be a try_realloc that would attempt to reallocate in place but do nothing on failure. Unfortunately most system allocators do not provide it [1] so it is kind of a catch-22 and most proposals never made it into the standard.
[1] jmalloc does provide xallocx that only reallocates in place though.
Copying large objects is significantly more expensive than copying small objects, and the cost is exacerbated due to cache effects. The C++ language contains a lot of optimizations for trivially copyable objects, e.g. std::copy, so having a realloc optimization for vectors would seem to be natural.
glibc malloc switches to mmap for allocations above ~128KB by default, which could be reached by vectors with just a few thousand elements (or a few very large objects). glibc does use mremap to reallocate mmap’d chunks - so in that sense the memory remapping hacks are already present in a general purpose library.
The reason for realloc is that often an allocator can extend an existing allocation in place if the next block is free (and this can be done without syscalls). As you described, except for trivially copyable objects though, realloc doesn't really work in C++, so a better allocator interface for C++ would be a try_realloc that would attempt to reallocate in place but do nothing on failure. Unfortunately most system allocators do not provide it [1] so it is kind of a catch-22 and most proposals never made it into the standard.
[1] jmalloc does provide xallocx that only reallocates in place though.