The prose earlier said it returns a dictionary of strings to AnnotationAST objects.

Though maybe a single AnnotationAST object would make sense? The namespace is the same for all annotations in a namespace, after all.

My original implementation used the layout that you're describing. But in the discourse thread David Ellis requested the nesting to be flipped in order to support synthesizing annotate functions more easily. Essentially, if each annotate object has its own reference to its namespace we can merge e.g. dataclasses from different modules without having to worry about namespace issues. The compiler generated annotate functions also don't actually create duplicate namespace objects, so memory usage isn't a big problem.

This layout also has the advantage that every annotation format returns a dict mapping variable names to some data. When I implemented the other version I had to add a lot of boilerplate case distinctions to things like the dataclasses or annotationlib modules.

Unrelated to the grammatical fix on this line: shouldn't this be bytes constants?

Currently the implementation is using genuine str objects. Bytes have the advantage that the encoding is slightly simpler since you don't need to worry about it being valid UTF-8. But strings let us intern them, which slightly reduces memory usage (about 1.5% of overall module/.pyc size). Execution time (both of the annotate call and module import) is the same for both types. I don't have a strong stance on which is better, if there's a reason to prefer one over the other I'm happy to just go with that.

We could build bytes interning as part of this PEP, but I guess strings are fine too.