In this thread, we've already talked about type checkers and documentation generators, both of which can use the __annotations__ dictionary legitimately.
They shouldn't be putting things in it, though, they should be extracting data from it when they're told to by means of a decorator. (I know the original proposal didn't mention using a decorator for standard type information annotations and advocated deprecating other annotations instead, but I think that was wrong and judging by some of the other posts in the thread it seems I'm not the only one). You pick the thing you're going to use annotations for and decorate your function with its "process this function by means of its annotations" decorator; there's no potential for conflict between tools since each function can have only one set of annotations anyway.
Right now, as I understand it, the last applied decorator would win, which means 'func._projectname__something' would be set to either sphinx or mypy. That means that order matters for completely orthogonal concepts. This is bad. UUIDs solve this, and all the earlier problems.
You've missed my point (that's not your fault; I could have expressed it better): the key '_projectname__something' won't be used, the keys _mypy__types and _sphinx__doc (or similar) would be.
- What would pydoc print for the function signature?
As I mentioned earlier, certain UUIDs might become de facto or de jure standards. In this case, projects that have common goals could settle on a common standard and publish a common UUID. Pydoc would know about these UUIDs (they would be published), and would know what to do for them. For UUIDs it doesn't understand, it could raise a warning, or simply ignore them.
Before you take my comments above as proof the we don't need UUIDs, consider the fact that we are currently discussing type systems, and our thoughts may change in the future. I don't mean that there will be successive standards, I mean that there may be competing standards, at least until we really know what the best one will be. This is a case where creating and abandoning UUIDs will be trivial, but where using 'type checker' is going to lead to confusion.
I don't think your comments prove that we don't need UUIDs, I just don't think they prove that we do. Decorators solve this problem adequately; the only issue that will arise is if annotations without a decorator are supposed to have some standard semantics. As more or less a tangential point, I think most of the advantages you've listed of UUIDs are counteracted by how unintuitive, unreadable and forgettable they are.