This is definitely going to break the container's invariants, yes. Key modification has to be done via modify() so as to give the container a chance to reindex elements. So if you are quite sure this is happening try to remove the offending behavior; after this my bet is that the invariant assertion will go away. Otherwise please get back here.
Just weighing in here with a related question. But first to say: I find multi-index to be invaluable. So thanks for a great library. In my code, the objects I am indexing against are altered elsewhere, and then my index owning code is notified. At this point, the index owning code calls: index.modify( index_iterator, NoOperationFunctor() ); That is, on the assumption that the modify function has no knowledge of what changes the functor are making, it must re-evaluate all indices. Therefore, it doesn't matter if the change is made inside the modify function as long as modify is called. (So, this statement from above does not appear strictly true: "Key modification has to be done via modify() so as to give the container a chance to reindex elements.") Because (in my case) the change is made elsewhere, I am calling modify with a functor that does nothing. In my particular case, I can guarantee that change made elsewhere won't affect the index that I use to find the iterator to pass to modify. This may seem a weird scenario, but it also seems weird that I have to call modify with a no-op functor. Is it possible/desirable to add a simple update_indices( itor ) function? Neil