Purpose of this series?

Going by the terminology in RFC 2094 I think this should ideally be called "temporary scope extension", not "temporary lifetime extension" (as the reference book calls it), to make the distinction clearer.

A value's scope is (by definition) the time span before its destructor is run, whereas a reference's lifetime is the time span during which you can use that reference. The lifetime of a reference obviously cannot exceed the scope of the value it's referring to (to avoid use-after-free). The lifetime must extend to at least the last piece of code that uses that reference, but may be longer; the exact length is (if I understand correctly) an implementation detail, not part of the language definition.

NLL is about making lifetimes shorter, within those constraints. Originally a lifetime would be either a single statement (which is fine), or a whole `{ ... }` block regardless of where the last use of the reference was, because that was easier for the compiler to implement. NLL allows lifetimes to end in the middle of a block.

Excessively long lifetimes don't affect the program's behaviour, but they can prevent you writing valid code that re-borrows a value soon after the last use of an old reference (when there's no aliasing danger but the borrow checker doesn't realise it's safe). NLL reduces that annoyance.

Scope (i.e. where destructors are called) does affect behaviour, and is part of the language definition. Local variables are straightforwardly scoped to their `{ ... }` block (unless moved), while unnamed temporaries have much more complicated rules (including the temporary scope/"lifetime" extension rules) in an attempt to be more ergonomic. The 2024 edition made some changes to those rules (but only for code that opts in to the new edition). When using types with non-trivial destructors, like lock guards, you do need to be somewhat aware of those rules; if in doubt, replace the temporaries with local variables so the scope is more obvious.