This consensus is a bit too hard line absolutest for me even though I agree with your closing opinion. That’s the problem that needs solving.
We need to get to the point where annotations in the stdlib are checked in our dev workflow and CI and a standard for which forms of annotations we allow vs not with specific reasons why.
I’m probably responsible for the errant-looking annotations within multiprocessing they helped understand the code. If we had checking within the stdlib, them being invalid from a type analyzer POV wouldn’t’ve happened.
We also have some stdlib modules that are semi-maintained externally for updatable third party use w/o upgrading Python itself; with code synced to the stdlib and stdlib changes synced to the external project. zipfile happens one of those IIUC? It ultimately makes developer life difficult if we require stripping of annotations when doing such syncs, lowers the maintainability of code, and dissuades contributions.
I’m not saying YOLO annotate everything in Lib/, just that a policy of blocking all annotations isn’t a healthy one for us to take in the long run. Type checkers themselves don’t use stdlib source annotations, they use typeshed. We need checked stdlib annotations for our own internal use. How do we get there?