OK, please find attached a preliminary patch for the functionality. This patch is complete in terms of implementation with one significant ommision, __setitem__ on the parser (adding a section), which needs further discussion.

Because of the development state for this functionality, the patch includes some comments that are meant to aid reviewers and the developer (me). They are obviously not supposed to be included in the final patch. There is neither any ReST documentation and only the BasicTest was ported to check for the mapping behaviour as well at the moment. All of these will be corrected once there is agreement upon the interface and its implementation.

The mapping interface implementation is using the parser['section']['value'] notation that seems to be more popular amongst the developers. The alternative implementation presented in the first patch shall not be included because "There should be preferably only one obvious way to do it". Implementing both approaches in a consistent manner would be needlessly tricky and would bloat the code, the tests and the documentation. I believe it's not worth it.

The mapping interface implementation enables getting parser['section'] which returns a mutable view on the section. This means that:
- the values are not copied but they are taken from the original parser on demand
- the values mutated using this view are mutated in the original parser

The implementation is using the existing high-level API so that subclassing the original interface makes the mappings work as expected as well. This has the drawback of having potentially weak performance (especially __len__ and __iter__ on a section). One difference is the explicit lack of support for the `__name__` special key. This is because the existing behaviour of `__name__` is very inconsistent and supporting it would only lead to problems. Details here: http://mail.python.org/pipermail/python-dev/2010-July/102556.html

The mapping interface was implemented so that it behaves as close to an actual dictionary as possible. The existing differences are:
- all sections do include DEFAULTSECT values as well
  -- these values cannot be deleted from the section (because technically they are not there). If they are overriden in the section, deleting causes the default value to be visible again. Trying to delete a default value causes a KeyError
  -- because of this reason, .clear() on a section does not leave the section empty
- trying to delete the DEFAULTSECT throws ValueError
- the mapping interface is complete thanks to using the MutableMapping ABC. However, there are two methods in the old API that hide the dictionary interface:
  -- .get() - this one is unsolvable even when we get to implementing default= for it because invoking as .get('string1', 'string2') would be ambiguous. This difference shall be explicitly documented in the docs.
  -- .items() - this one could potentially be solvable by providing a special case when no arguments are passed. The problem is with existing subclasses (possibly 3rd party) which override this method without handling this case. I'm still on the fence whether to include a special case here.

As for adding a section with the mapping protocol access, I like the current behaviour used for instance in ConfigObj is good for us. They use something like:

parser['section'] = {'key1': 'value', 'key2': 'value'}

This should overwrite existing sections as well. If no-one objects, I'll implement this behaviour as well.