It doesn't make sense to make any of these changes to Python 2; this
really should have been separate from the documentation issue.  That's
probably understood by everyone, but explicit is better.


Merging implementations
-----------------------

- I've no objection to merging RawConfigParser and SafeConfigParser,
  using a constructor argument to control whether interpolation is
  performed.  It's not clear this provides any improvement in
  maintainability or usage.

- Isolating the old (broken interpolation) ConfigParser behavior so it's
  not in the middle of the inheritance stack would be good.


Changing ConfigParser behavior
------------------------------

Changing the behavior of the ConfigParser name requires the deprecation
process.  We may think nobody in their right mind is using that, but
changing something out from under app developers is really bad.  This
should be considered a problem for configparser as outlined in msg 112598.

Whether we can assign new semantics to the ConfigParser name in the
future is questionable.  I think Python's compatibility policy allows
it, but that doesn't make it a good idea.

(This seems to be the real sticking point, unfortunately.)


Class names
-----------

I don't understand Michael's objection to adding new names for the
configparser classes; that's one of the few points where we don't run
into backward-compatibility black holes.

In the case of a merged implementation, a new name for the merged class
(possibly "Configuration") may be the best bet; the old names can then
be subclasses of that which generate appropriate deprecation warnings.