I did several more experiments to reproduce the reported problems and narrow down when they occur.  (Where I say 3.6.3 below, I actually tested 2.7.15 and/or 3.5.4 and assume same behavior until fix for 3.6.4.)

>>> a=1
>>> a
1  # no extra space
>>> d={1:'a',
       }  # 3 space autoindent in 3.6.3-, 7 in 3.6.4+ after fix.
>>> ===  # 2nd '=' marked with red 'error' background
SyntaxError: invalid syntax  # no extra space for this SyntaxError
>>> a
1  # no extra space
>>> d={1:'a
       |<-- 3 or 7 space indent in 3.6.3-, 3.6.4+
SyntaxError: EOL while scanning string literal
>>> a
       |<-- Regression: persistent only after fix
1
>>> if a    : d={1:'a
		|<-- new indent, 2 tabs + space, correct
SyntaxError: EOL while scanning string literal
>>> a
		|<-- extra line with larger indent.
1
>>> if a              : e{3:===}
		|<-- indent not increased with matched {}.
SyntaxError: invalid syntax

Fresh start:
>>> a=1
>>> d==={  # error before unmatched {
	|<-- indent
SyntaxError: invalid syntax
>>> a
1

Conclusion: IDLE has had a buglet in adding an indented blank line before 'SyntaxError' when the erroneous line (or maybe statement) has an unmatched opener.  Before 3.6.4, indents after unmatched openers in the first line of a statement were wrong because the prompt was ignored.  However, the fix introduced a regression in making the corrected indent persistent.  I will have to check whether the persistence is from an uninitialized value or from erroneously including prior statements in the calculation.

If possible, check syntax first and only request a smart indent when the statement is correct but incomplete.  This should fix the buglet and might nullify the persistence, though I would like to fix the persistence also.
---

I have occasionally experienced unrequested pasting of previous input or output after the 1st prompt after a restart, but it is so rare for me that I have not yet detected a pattern.