There are 2 questions.  1. Should we review squeezer, in light of further complemplation and experience, and possibly patch it in a couple of weeks or so?  Yes.

2. Is there such a severe bug that we should possibly rush a fix and ask Ned to cherry-pick something after the well announced deadline?  Since I see behavior different from your report, I don't currently see a reason to ask.

I have tested with Windows 3.7.1 64 bit installed, Windows 3.7.2c1+ 32 bit repository debug build from yesterday, Mac 3.7.2rc1 64 bit installed.

'a'*200 and 'a'*200 + '\n' both display over 3 lines and are *not* autosqueezed.  Both squeeze as 3 lines.  Unsqueeze, narrow window, and resqueeze, and the result is *4* lines, not 3.  Line single lines with 20000 and 20002 characters, a'*20000 and 400 * (48*'a'+'\n),  are autosqueezed, as more than 250 lines, depending on the window width.  Note interactive echo uses repr(), so that the '\n' converted to 1 newline is converted back to '\n'.  Lines here also depends on width.

print(200 * (70*'a'+'\n')) is squeezed as 200 lines regardless of wrapping or not.   So the effect of wrapping on line count depends on the number of lines.

print(40 * (100*'a'+'\n')) (4000 chars) is not squeezed, even though it would be by the 50 lines * 75 chars/line (3750 chars) rule I suggested.  

Further experiments shows that autosqueezing only applies to single writes to sys.stdout (and maybe to sys.stderr).  print(40 * (100*'a'+'\n'), 40 * (100*'a'+'\n')) prints 40 lines twice with separate write calls and is not autosqueezed.  Manual squeeze squeezes contiguous  stdout or stderr blocks even if the former is the result of more than one print arg or calls.  Stdout blocks separated by an input() response are autosqueezed separately.  This all seems fine.  The doc could use a few more words.