Ned, thank you for the helpful response.  Yes, I *was* proposing two versions in 3.5 and subsequent releases until the current version could be deleted.  Its an ugly, least bad alternative that only made sense under the presumption that 'idle2' had to remain in 3.6.   With that assumption dropped ...

I would be delighted to start renaming (and refactoring) existing files in default *now*.  Whether to renames all at once (the current #24225 proposal) or in batches would be a sub-issue of #24225.

I believe that the PEP 434 exemption from separating 'behavior' from 'enhancement' issue applies during the beta period as well as after.  For IDLE, danger of accidental regression and thoroughness of testing are more relevant for deciding timing of commits.

As for 3.5, if we assume that substantial numbers of people, including instructors, will use the final 3.5 (likely 3.5.3) instead of 3.6.0, then it might be better for users to include 'idle3' in 3.5.3 as an option.  This could be done a couple of weeks before the release by copying 3.6 idlelib into, for instance, 3.5 idlelib._, editing imports, and adding a switch to the startup code.  If Ned's alternative is accepted, the backport decision should be deferred until there is something worth backporting.