+0. We should try and be consistent even if this is a thing I don't want. And trust me, I don't! 

That said, as long as pro-mypy people are willing to make everyone else pay a mypy reading tax for code let's try and reduce the cognitive burden.

* Duplicate type annotations should be a syntax error.
  Duplicate annotations aren't possible in functions so that wasn't an issue in 484. 526 makes some things syntax errors and some things runtime errors (for good reason -- function bodies aren't evaluated right away). Double-annotating a variable is something we can figure out at compile time and doing the double annotating is non-sensical so we should error on it because we can.

*  Dissallowing annotations on global and nonlocal
  Agreed, allowing it would be confusing because it would either be a re-definition or a hard to read annotation-at-a-distance.

* Where __annotations__ live
  It is strange to allow modules.__annotations__ and MyClass.__annotations__ but not myfunc.__annotations__ (or more in line with existing function implementations a myfunc.__code__.co_annotations). If we know enough from the syntax parse to have func.__code__.co_varnames be known then we should try to do that with annotations.  Let's raise a SyntaxError for function body annotations that conflict with same-named variables that are annotated in the function signature as well.

I did C++ for years before I did Python and wrote C++ in many languages (including Python). So ideally I'm -1000 on all this stuff for cultural reasons -- if you let a C++ person add types they will for false comfort. But again, I'm +0 on this specific proposal because we have already gone down the garden path.

-Jack