Here's a possible solution to the rereading problem.  It should allow
existing applications to work whether they behave properly or not, as
well as (probably) most third-party subclasses.

The idea is to compare the new table of contents to the list of known
offset pairs, and raise ExternalClashError if *any* of them have
changed or disappeared.  Any new pairs can then be added to _toc under
new keys.  To maintain the list of known pairs, a special dict
subclass is used on self._toc that records every offset pair ever set
in it - even those that are subsequently removed from the mapping.
However, if self._pending is not set when rereading, then the code
doesn't rely on this special behaviour: it just uses
self._toc.itervalues(), which will work even if a subclass has
replaced the special _toc with a normal dictionary.

Ways the code can break:

- If a subclass replaces self._toc and then the application tries to
lock the mailbox *after* making modifications (so that _update_toc()
finds self._pending set, and looks for the special attribute on _toc).

- If a subclass tries to store something other than sequences in _toc.

- If a subclass' _generate_toc() can produce offsets for messages that
don't match those they were written under.

File Added: mailbox-update-toc-again.diff