Hmm.  Sorry for the stream-of-consciousness thought process here, but this approach adds wrinkles too.

Function objects from the very beginning have lazy-created their annotations dict if it's not set.  Which means this works fine:

    while True:
        del fn.__annotations__
        print(fn.__annotations__)

You can do that all day.  The function object will *always* create a new annotations object if it doesn't have one.  del fn.__annotations__ always works, and accessing fn.__annotations__ always succeeds.  It doesn't retain any state of "I already lazily created one, I shouldn't create another".

If I add getsets to classes and modules so they lazy-create annotations on demand if they otherwise aren't set, then either a) they need an extra bit set somewhere that says "I lazily created an empty annotations dict once, I shouldn't do it again", or b) they will duplicate this behavior that functions display.

a) would better emulate existing semantics; b) would definitely be a user-visible breaking change.  There's actually a test in the Lib/test/test_opcodes (iirc) that explicitly tests deleting __annotations__, then checks that modifying the annotations dict throws an exception.  I haven't done any investigating to see if this check was the result of a regression, and there was a bpo issue, and there was a valid use case, etc etc etc.

My instinct is that deleting o.__annotations__ is not an important or widely-used use case.  In fact I plan to recommend against it in my "best practices" documentation.  So either approach should be acceptable.  Which means I should go with the simpler one, the one that will duplicate the function object's always-recreate-annotations-dicts behavior.