Adding a "DeprecatedSyntaxWarning" that's a subclass of both DeprecationWarning and SyntaxWarning (and hence silenced by default while still having the extra SyntaxWarning attributes) strikes me as a reasonable step to take here, even though we're into the beta period already - if we couldn't effectively respond to this kind of pre-release usability feedback, the beta period would be nowhere near as effective.

Ideally, this would also let you hook into the same system that ensures syntax warnings are correctly attributed to the code containing them from a warning filter perspective, rather than the import statement triggering the compilation. One possible way to do that would be to postpone generating this error to a later stage of the code generation pipeline rather than doing it directly in the parser.

Otherwise folks trying to constrain "-Werror" to just their own code and not their dependencies are going to have a bad time of it. If we find we can't readily fix that aspect of the change, then I'd go so far as proposing to revert it and trying again for 3.7. If we do find we need to take that step, we could still encourage linter developers to start complaining about unknown escapes during the 3.6 cycle.

P.S. As general background, the "No new features after beta 1" rule is more accurately written as "No new features after beta 1, *except* for features needed to resolve usability problems reported with changes that already landed in beta 1". The biggest one of those I've seen was the PEP 492 implementation for 3.5, where the implementation data model was originally still just "generators with a particular flag set" (similar to the 3.4 model), but the Tornado and Cython folks found that unworkable after the beta went out, so we made both the Python API and C API expose them as distinct classes with different attributes (cr_* instead of gi_*) and different ABCs that the asyncio checked for.