It could be the implementation detail if locals() calls were not useful to majority of Python software, and if behavior of its returned dict did not affect the execution flow of user programs (was deterministic for users who should not care about the implementation details).

What I proposed initially is to wrap the locals(), the dict it returns and various calls that update this dict into a pattern called "livedict". This pattern has a defined behavior, and in OOP it would be encapsulated in a single object with one private method locals.__update (called by FastToLocals and other internals), and accessor method locals.todict() (name may vary) to receive a static copy of the live cache. If somebody needs access to real-time updated symbol table, it may request to work with realtime API of this locals object instead. This API is turn could have an implementation detail that transparently provided faster access to the local symbol table than copying dict into cache every time.

Wrapping this into a pattern also makes it easy to communicate details in case other Python implementation breaks this implementation detail of CPython. It may be easier for understanding to start with broken aspect of the pattern without digressing into implementation details, and read about implementation details later, than to go other way around.