Running the attached script shows that locals() behaves differently
depending on whether sys.settrace() is active.

This does not occur when calling locals() in the global scope, only when
used inside functions.

The same is thing is true of the frame's f_locals attribute. This
attribute is a copy of the local variables in the frame, because the
internal storage of these variables is a raw C array for faster access.
This copy is only synchronized back when a tracing function returns, so
as to allow implementing a debugger.

>>> def f():
...   a = 1
...   l = sys._getframe().f_locals
...   b = 2
...   return l
... 
>>> f()
{'a': 1}

The above optimization (raw C array for faster access of local
variables) is not done at the global scope, and therefore locals() at
that scope give you direct access to the variables' internal store
(which is, actually, the module's __dict__).

>>> import __main__
>>> __main__.__dict__ is locals()
True

So there's no bug here right? It's even documented.

It's documented that "The contents of this dictionary should not be
modified; changes may not affect the values of local variables used by
the interpreter."

The script does the opposite. Perhaps an addition to the documentation?
"The contents of this dictionary may not be affected by local variables
used by the interpreter".

I think the doc is clear enough if one reads and believes it.  The main
doc is "Update and return a dictionary representing the current local
symbol table." That pretty clearly says that subsequent changes to the
local symbol table may make the dict out of date until updated by a
subsequent call.