So the diff would look like this (please find it attached). It does two things:

* changes messages on InterpolationMissingOptionError and InterpolationDepthError to be more helpful to the end user
* fixes rawval to actually hold the raw value of an option and not the "rest after substitution" like before

Fred, R. David, I have two questions for you:

* the reliable method of getting the arguments of both exceptions is the .args attribute; this didn't change but the message did. It's unlikely anybody would be parsing the old message string, but even if there was I'm inclined to treat any code doing so as broken by design. Do you agree?

* without the diff, the `rawval` argument in those exceptions holds a value that exposes internal implementation and is not generally useful for user code. It wasn't exposed directly as an attribute in those exceptions (`section`, `option` and `reference` are). That being said, fixing this is a change in logic of sorts. Do you see any danger of third-party code relying on the old behaviour?

Actually, I have a hypothetical third question:

* Should I make sure that those exceptions are unpicklable by older releases of Python 3?

I'm asking because if there's no such expectation, we could add .rawval as a direct attribute to InterpolationMissingOptionError, and introduce `reference` to InterpolationDepthError (currently the exception message can say that "option O in section S contains an interpolation key that cannot be substituted" but it doesn't say which interpolation key).

Anyway, the first two questions are most important because they basically decide whether we can change the exceptions at all at this point. I'm inclined to say "yes", Python 3 did that with a number of exceptions both built-in and in the standard library.