It is the constness of the container which should control whether
it can be modified through a member function such as erase(), not the
constness of the iterators. The iterators only serve to give
positioning information.

Here's a simple and typical example problem which is currently very
difficult or impossible to solve without the change proposed
below.

Wrap a standard container C in a class W which allows clients to
find and read (but not modify) a subrange of (C.begin(), C.end()]. The
only modification clients are allowed to make to elements in this
subrange is to erase them from C through the use of a member function
of W.

The issue was discussed at length. It was generally agreed that 1)
There is no major technical argument against the change (although
there is a minor argument that some obscure programs may break), and
2) Such a change would not break const correctness. The concerns about
making the change were 1) it is user detectable (although only in
boundary cases), 2) it changes a large number of signatures, and 3) it
seems more of a design issue that an out-and-out defect.

The LWG believes that this issue should be considered as part of a
general review of const issues for the next revision of the
standard. Also see issue 200.