Instead 'hackish', maybe I should have used 'magic'.  The overloading just wasn't obvious to me, meaning I have:

self.font_bold = tracers.add(BooleanVar(parent), self.var_changed_font)
self.space_num = tracers.add(IntVar(parent), ('main', 'Indent', 'num-spaces'))

We defined VarTrace as being (var, callback) pairs and the second example isn't sending a function.  So, even though I understand what we're doing, I wanted to ask about using different names for my own education.  I was even thinking of a different interface --

add(var, callback=default, config=None)

If config was specified even for the non-default callbacks, then each var could have its config defined at create time instead of in the var_changed* function.  This wouldn't work for theme/keys `name` and `name2` though (I think that's the only one with two add_option calls).  If the callback didn't have a changes.add_option, then it can send None for config.

I hadn't thought of separating `parent`, but I like that idea.  It fits in with the rest of how the widgets are created. 

So, if both changes were incorporated:

self.font_bold = tracers.add(parent, BooleanVar, 
                         callback=self.var_changed_font, 
                         config=('main', 'EditorWindow', 'font-bold'))
self.space_num = tracers.add(parent, IntVar, 
                         callback=default, 
                         config=('main', 'Indent', 'num-spaces'))

Maybe that expands VarTrace too much?  Or maybe instead of (var, callback) pairs, it's a dictionary?  tracers = {var: (callback, config)}

And then the non-default var_changed methods could use:
changes.add_option(*tracers[var].config, value)

Wouldn't work for var_changed_font because that has the three add_option calls.