Glad to be of help with regards to 8.4 :=)  With my 3.6 release manager hat on, I think the best way to think of this is as a new feature: call it "Ttk IDLE" or some such (and not idle2 vs idle3 which I think is confusing) and, rather than inventing something new, I suggest you should just follow the standard procedure for new feature development as documented in the Developers Guide.  That is, create a temporary repository on hg.python.org and make all the changes in a new branch in that repo.  Or, if you'd rather work in private, just create your own local repo clone and branch within it.  When you are satisfied that it is ready to be integrated into the release, we can either merge the branch in or extract the changes as one big patch to be applied to the main cpython default branch.  And I'll be happy to help with making that happen when the time comes.  That way you and any one else wanting to work on IDLE can work unimpeded, you don't have to worry about temporary changes and hacks to accommodate two versions of IDLE in the same repo, the old version of IDLE continues to work in the main cpython default branch until TtkIDLE is ready, and the cpython repo is not cluttered with all the intermediate commits from the feature dev cycle (although they could be preserved during integration, if desired).  Plus, during feature development you should be able to use TtkIDLE from the feature repo with a standard 3.6 (or 3.5) binary install of Python.

As for timing, I would prefer to get such a major feature in by feature code cutoff but, as you say, IDLE is pretty self-contained so we can be flexible.  A similar argument would apply to 3.5.  But I think it makes sense to focus on 3.6 first and then later separately consider dropping it all into 3.5.x, a decision that would be up to Larry as the 3.5 release manager.  For 3.6, I don't think there's a need for further discussion or to wait to begin, as long as the development work is done in a feature repo.  Have at it!

https://docs.python.org/devguide/committing.html#long-term-development-of-features

By the way, if you are essentially replacing the IDLE files, then (contrary to what I suggested earlier) you probably don't want to use hg mv to rename files.  Otherwise you can end up with needless merge conflicts between 3.x branches.  In the feature branch, you can just do the equivalent of: hg rm Lib/idlelib and hg commit then copy any old idlelib files you want to retain back into Lib/idlelib, and do an hg add and hg commit.  Then the feature branch files are no longer "connected" to the old IDLE files from hg's perspective.  On the other hand, if you go the feature repo route, you won't have two copies of IDLE in the same branch at a time, so you don't *have* to rename files if you don't otherwise want to.  In any case, if the feature is integrated as one big commit, all of this can be handled at integration time.