Terry, I'm all for having IDLE using the newer Ttk widgets and for refactoring to make it easier to enhance and maintain IDLE.  I'm not sure I understand the proposal to make two sets of IDLE files: does this mean there would be two versions of IDLE in one branch, e.g. Python 3.6?  That doesn't make sense to me.  One issue you mention is continuing to support Tk 8.4 (which lacks Ttk) on legacy systems.  Tk 8.4 support ended some years ago by the Tcl Core team. I think it is time for us to draw a line in the sand and say we no longer need to continue to support it for IDLE.  (It would be nice to not intentionally break basic non-IDLE Tkinter support for 8.4.)  I haven't yet announced any proposals for Mac installer support for 3.6 but I'm willing to commit to not requiring any Tcl/Tk 8.4 dependencies.   So, if we assume 8.4 is no longer an issue, what other issues remain?  I believe you've already stated that you will no longer attempt to keep the 2.7 version of IDLE in sync with the latest IDLE 3; I thinks that's the right approach at this stage.  That means there will be only some backporting of selected IDLE bugfixes to 2.7 and we don't do any direct VCS merging between 2.7 and default anyway.  So it seems to me there is no reason why the default branch (e.g. what is going into 3.6) needs to retain any copies of IDLE files from the 2.7 branch.  In other words, all the file renamings (via hg mv or otherwise) and deletions just take place in default without disturbing 2.7.  If there are any external incompatibilities, it's fine to announce them as part of the 3.6 feature release.  This is assuming that the externally incompatible work is in place in time for the 3.6 feature code cutoff (3.6.0 beta 1, currently scheduled for 2016-09-08).  As far as 3.5.n is concerned, the last bugfix release for 3.5 is likely to be less than a year away (assuming 3.6.0 releases by the end of 2016 as planned).  So I would also recommend not making any refactoring changes for 3.5, just important bugfixes similar to 2.7.  We should try to make it easier for you and the others working on IDLE.  And try to minimize the risks of inadvertent breakages going into maintenance releases.  Does that make sense?