There is a reason that I said, in msg266221, that I would experiment with moving 1 feature ;-). I knew from past experience that changing anything that affected user configuration would have to consider the effect on previous releases.  A total 'clean break' now would mean not a Py2 versus Py3 set of files but a Py3.6.2- versus a Py3.6.3+ set of files and I will not do this.

But it is OK with me that you plunged ahead to learn for yourself.  I expect to use most of what you have done.  I would like to get this into 3.6.3, whose release candidate is scheduled for late September.  But see below. That I one reason why I have focused for the last month on getting config and configdialog ready for changes.

When I said, in msg298982, that the extensions tab has 'a separate system for handling user changes', I meant for putting user changes into idleConf.  IdleConf itself handles the 2 sets of 4 files (or the 4 pairs) uniformly.  I intend to remove that separate system *before* working on this.  The changes instance of the new config.OptionChanges is already initialized with an 'extensions' dictionary that corresponds to the idleConf.userCfg['extensions'] instance of IdleUserConfigParser.

So, *do not change your patch to use the separate system*! I expect that we should just need to replace 'main' with 'extensions' in something like "changes.add_option('main', 'AutoComplete', 'popupwait', value)".

Changes that impact users should have a net user benefit, either directly or indirectly.  Moving menu entries, making the menu different in different releases, will bother some people, but I think a few changes will be justified.

Moving the tab where non-key options are displayed and changed also makes successive releases different.  The (potential) benefit is that it will be easier to select and check entries.  I just discovered that one can currently set editor width, for instance, to the string "nonsense"!. So the other tabs are also deficient. The benefit needs to be that entries, both existing and added, *are* checked.  Moving the file where non-key options are *stored* has no user benefit to counter the severe incompatibility problem.  Satisfying my aesthetic sensibilities is not good enough to justify the breakage.

Extension key-binding options are already displayed on the keys tab.  The issue is saving *all* key changes to the key file.  The user benefit is to make it easier to design a new custom keyset.  Some people do this by copying a section into config-keys.cfg or a separate file and editing it in an editor with enough lines to see everything.  This seems easier than laboriously scanning the box showing 10 bindings at a time and changing one at a time with the popup.  But the editor method misses the extension binding.  In any case, even after adding an error check from a 2009 submission, there are 9 remaining keys issues and as many potential issues on my list.  Improving the keys tab for all bindings is as important as moving the storage of some.

Changing existing non-buggy behavior is much more problemmatical than fixing buggy behavior or adding new behavior.  So we could defer the above changes to 3.7.  But I don't like that either.  It deprives 3.6 users, which there will be for several years, of the benefits.  Diverging the files would make backing other improvements to 3.6 harder and less likely.

This issue is worse for the big change to tabbed windows.  Proposed solution: make tabbed windows a 'beta preview' option for the 3.6.x release after a minimal version is ready.  (There would be the option of leaving the option in 3.7, though perhaps as opt-out.) 

The same could be done with the changes in this issue.  Make them opt-in in 3.6.  Add 'Preview' before 'Help' with two items on the drop down: 'Explanation', and 'Selected'.  Explanation would popup a text view window.  Selected would set a variable.

I am working on removing from ConfigDialog a class for each tab.  When that is done, we put the opt-in changes for this issue in a subclass of each.  Then ConfigDialog