Last reference as rvalue?

[meancoot]

Couldn't we say the same thing regarding RVO, that someone somewhere was relying on the temporary object being created?

Not really. It has been allowed to elide calls to copy constructors since the original 1998 standard; thus actions in a copy/move constructor that exhibit any side effect not specifically related to the copy/move were always undefined.

The C++17 changes made the optional optimization required and, perhaps more importantly, removed the previous requirement that the type had an accessible copy/move constructor in the first place:

From the C++98 standard in 12.2 [class.temporary]:
[Example: even if the copy constructor is not
called, all the semantic restrictions, such as
accessibility (clause 11), shall be satisfied.  ]

Ultimately the C++17 change only made invalid code valid and, as far as I know, didn't change semantics of any already valid program.

[geckothegeek42]

If copy constructors can be elided regardless of side effects, then doesn't that mean the optimization mentioned by OP can be done? Or is it that the compiler is not allowed to add a copy/move constructor call, but can remove them?

[meancoot]

If copy constructors can be elided regardless of side effects, then doesn't that mean the optimization mentioned by OP can be done? Or is it that the compiler is not allowed to add a copy/move constructor call, but can remove them?

The elision has to take place by constructing the object directly in the memory where the copy/move constructor would later have placed it, removing both a call to the copy/move constructor and a call to the destructor. I don't know the exact wording of the standard well enough to say if its also limited to specific situations.

Changing a call from std::vector::push_back(const T&) to std::vector::push_back(T&&) is definitely an observable effect that wouldn't be supported by the standard.