This is not what type checker changes look like for libraries. For a library, you basically put your annotations out into the world and cross your fingers – you don’t control the type checker version or flags at all.
This is true of course and something to consider indeed. I also maintain some libraries and can see how this could lead to problems where a “downstream” package uses a type checker that can’t recognise the concepts/behaviour as used by an “upstream” dependency of it.
However, to me this argument is of slightly less importance as the type checker of the “downstream” package already isn’t perfect, because, as stated many times before, the current type checkers all have their flaws and incompatibilities. Incompatibility between the type checker (and thus the typing) of package an and package b are already a possibility. This PEP does not change the status quo.
I understand that people want A more useful and less divisive future for typing?, but I don’t think we should arbitrarily apply a stricter interpretation of breaking changes to one particular PEP. It’s clear that Proposal 1 as mentioned by Eric is much better for the future users of Python and we shouldn’t let some theoretical discussion with very few actual real world issues prevent that future from materialising.