{ std::string s; }

see "scope" in my original comment

This could happen any time you return a pointer to a variable with automatic storage and then later attempt to dereference the pointer and do something with the value. Of course, you shouldn't do that, but the C++ compiler won't stop you. 'Scope' can have various meanings, but merely understanding how lexical scoping of variables works is not sufficient to understand why you shouldn't do that.

well, let me rephrase "scope" as "lifetime of objects"

Ok, but then what you're saying is almost tautological. Indeed, you won't be surprised when an object is destroyed in C++ if you understand how object lifetimes work in C++.

As I recall, the issue in my case involved a default copy-constructor which destructed an object wrongly. I’ve since learnt to delete the implicit methods of a class, but I still find reasoning about copy and move semantics to be thoroughly puzzling.

i would still think this is a misunderstanding of scope. and you really don't want to be worrying about move semantics unless you are a performance maniac, a library writer, or (most likely) both.