The reference itself is indeed valid, in the sense of existing, until it falls out of scope. But the object it references may not be, so using the reference can be UB. Consider an std::vector v with length known to be at least 1:

    const auto &ref = v[0];
    v.push_back(42);
    cout << ref;

That works fine until push_back reallocates out of place, at which point you may start to notice that it’s actually UB.

Rust will not permit this problematic usage. GC languages tend not to offer this pattern — you can reference a boxed vector element with different semantics than the above C++ code, and you mostly can’t reference an unboxed element. C++ lets you do things like this but has little ability to statically verify correctness.

(Doing the above maneuver with a vector is a bit silly: it saves typing, and indexing a vector is extremely fast. With a map, though, indexing is not so fast, and keeping an iterator or a reference around may be a big performance win. At least if you keep an iterator around, dynamic checkers have a better chance of noticing errors.)

I think the point is just that unlike Rust there's no compiler enforcement that you only use refs in their lifetimes: you can easily accidentally cause a use after free.

Some times it can be pretty indirect: eg if the ref ends up pointing into some std container then it might need invalidated by making an otherwise unrelated change to the container.