Original IDLE Dark patch: #24820. Follow-up for cross-version issues (initially for themes, but with a eye to keys, etc): #25313.  I intended that 'name2' be future proof (msg252372). I believe my idea was that if it were to point to a future 4th default theme that did not exist, there would be a graceful fallback to 'name', which defaults to IDLE Classic. But I am not sure if I tested this, so I should recheck.  If it does not work, a fix should go in all current versions. I believe the patch did achieve no warnings for older versions, as least on my machine. 

I would have the same goal for keys: no warning, future proof.  A test of the latter before committing requires two independent repositories, both with the patch, one with the extra definitions.  I currently have two 3.6 repositories and will do such a test once we have code that we think should work.

When one selects IDLE Dark as Default Theme, active or not, a subdued red message is displayed: "New theme, see Help".  (The latter part should change to a more explicit "click 'Help' below" so there is no possible confusion with the main menu Help. The Highlighting specific part of the popup suggests saving IDLE Dark as a custom theme, with a new name, This makes the theme available to older versions and solves compatibility problems.  The same would apply to a new key set.

In #24781, Mark Roseman proposed revamping the preferences dialog, both externally and internally.  The main idea for the Theme tab is to present users with a single list of available themes and (mostly) hide the builtin versus custom distinction.  (It cannot be ignored completely as builtins cannot be deleted and editing requires saving as custom.)  https://bugs.python.org/file40111/highlight3.png has an image.  We might consider the same idea for key sets.