If I read [basic.start.term] p3 correctly, destructors are essentially
called in the reverse order of constructors. I assume implementations
still can in theory eagerly call constructors for thread-local variables
on thread start if they want to avoid the necessary per-thread
bookkeeping. However, that possibility does not exist for thread-local
variables that are defined in run-time loaded modules (think dlopen).
(The dynamic loader cannot switch to the appropriate threads and call
the constructors there, the calls have to happen on demand on the
respective thread.) These issues around dynamic code loading are out of
scope for the standard, but that does not make them go away.

Anyway, for on-demand initialization of thread-local variables, an
implementation has to track the construction order for on-demand
initialization of thread-local variables, so that the destructors can be
called in the reverse order. This typically increases the amount of
thread-local storage for such variables by 50% to 100% (because the
order is thread-specific, and it has to be recorded somewhere).

What's the reason that this requirement was put into the standard?
Destruction order of singletons is tricky, and the suggested order does
not work in all cases. (If I recall correctly, Andrei Alexandrescu
discusses the surrounding issues extensively in Modern C++ Design, in
the context of regular, non-thread-local singletons.)

Thanks,
Florian