As you gave the code, the two windows just sit there with mainloop running.  Replace it with
root.update()
#w.close()
root.destroy()
and run from IDLE editor and I see the ".!menu.windows" message.  Uncomment the close and it goes away.

Root.destroy recursively calls the .destroy methods of its children.  Here, ListedTopLevel.destroy is called.  It calls TopLevel.destroy and registry.delete.  Its menubar child and its dropdown submenu are also destroyed.  But LTL.destroy does *not* call the close method of the EditorWindow instance (which is *not* a widget).  Without a reference, it cannot.

Registry.delete, which is called for each ListedTopLevel *calls all the callbacks*, which it exactly should not do at shutdown.  It does not unregister the associated callback.  That is part of editor.close.

In IDLE's normal operation, editor.close must somehow get called.  In test setups and teardowns, I am careful to undo things in reverse order of creation.  It is, in a sense, a bug, as things now stand, to create an OutputWindow(root) without calling its close method before destroying root.

In configdialog, the callbacks are the Var tracers.  The configdialog test teardown removes them all.  Closing editorwindows should do the same.  This is not to deny that making shutdown less fragile would be a good thing.

I think having separate EditorWindow and EditorFrame classes that *are* widgets would help, as then better auxilliary shutdowns could be either part of or called from the destroy methods that get called when root.destroy is called.

Aside from the ".!menu.windows" message in the idle shell, messages like the following appear in the command window if there is one, with or without the editor.close() call.

 invalid command name "96611576font_timer_event"
    while executing
"96611576font_timer_event"
    ("after" script)

"89887864font_timer_event"
    ("after" script)
invalid command name "89718392timer_event"
    while executing
Functions timer_event and font_timer_event are CodeContext methods.  The messages don't appear if code_context is not enabled.  I don't know how the messages are prevented (normally) when CondContext is enabled.  The is no obvious graceful shutdown of the loops.  They seem to end when self.text no longer exists so that self.text.after must fail.  I already knew that this class needs work ;-).