The present hierarchy (in this pull req) is that ``OptparseResult`` is a subclass of ``InterfaceOutputOption`` which is a subclass of ``InterfaceOption``. This pattern simplifies the configuration file as only a single list of options is necessary to maintain, and reflection can be used to determine what objects are used for the actual options that optparse generates. 

I do not see how this complicates the configuration since we're already specifying a name, key and handler for each output. I support limiting what we track on an ``InterfaceOutputOption`` (e.g., not tracking shortname/longname, etc) as I already indicated. 

Please keep in mind that while there may not be a specific benefit right now in having some of these details for optparse, we need to stay focused on what will generally be needed.