Treating a SyntaxWarning as an error is intentional, since 2001 in a Kurt Kaiser patch.  IDLE's ModifiedInterpreter subclasses code.InteractiveInterpreter.  The subclass .runsource turns a SyntaxWarning into an error, before calling the superclass method, with

    warnings.filterwarnings(action="error", category=SyntaxWarning)

As long as this is true, it should be documented.  It is included in #37825.

In interactive python (as opposed to IDLE), code is executed after a SyntaxWarning.  In the non-callable call examples, minimally "()()", "[]()", "1()", and "''()", the result is a traceback that repeats the warning message. I think the repetition is mostly noise and is better omitted. I don't know what SyntaxWarnings were present in 2001, but I presume that Kurt had the same impression, whatever it or they were.

The non-callable calls violate the 'ideal' Python grammar, which would have a production like "call = possible_callable '(', args, ')'.  Violations are caught by the compiler rather than the parser.  But they could plausibly be called a (subclass of) SyntaxError and execution avoided everywhere.

The situation is quite different with "literal is (not) something", where 'literal' includes constant tuples.  The expression is valid, normally runs without exception, and should be executed. To me, this is not a syntax issue, so SyntaxWarning seems wrong.  But as long as is used for this situation, the conversion to error must cease.  (If I knew how, I would prefer to still not call known non-callables in Shell.)

There are two subcases with different reasons for pinging users.

1. The result is obvious ("0 is ''", "0 is ()") and unchanged when 'is' is replaced with '=='.  The advice is useless.  It should instead, it seems to me, be to use True or False.  I suspect that this case is rare.

2. The result using 'is' is implementation dependent ("0 is 0", "0 is a", "1000 is 1000"). For production code, the advice to change 'is' to '==' is correct. For exploration of 'is' in a shell, which many beginners like to do, it likely is not, at least not immediately.
--

My initial messsage above is moot since compile("assert (0, 'bad')", '', 'single') no longer emit a SyntaxWarning, and the new warnings do not show the same behavior, even for similarly legal code such as "0 is 0".

My second message, about when a SyntaxWarning for a file is displayed, is still relevant, and I agree that it is a higher priority than before.  

But it is more complex than reported above.  First, there are other warnings than SyntaxWarning, and we might decide to optionally enable them.  Second, Run Module does Check Module first.  If Check Module is selected directly, there is no restart line.  Third, there will be no restart line if there is a SyntaxError, or a Tabnanny but there might be prior warnings.  I think I know how to deal with all of the above.

Module SyntaxErrors and Tabnanny errors are displayed in a popup error box, with the cursor moved to the line and maybe column of the error.  Warnings could be put in a separate box unless there is a restart.  I would prefer to not shift focus to Shell unless and until a module is run.