I discovered this when trying to add support for persistent CompositionUnderline spans to support the Android Voice IME.

DocumentMarkerController::m_markers is a hash map from Node* to a vector (indexed by DocumentMarker::MarkerIndexType) of vectors of DocumentMarkers. I added a new MarkerType and MarkerTypeIndex for a persisting CompositionMarker. I spent several hours trying to determine why my markers were getting cleared despite having commented out all the methods I could find for removing them and found this bug.

There's a check in addMarker() to see if we've created a MarkerList for a given MarkerTypeIndex. If it fails (e.g., we've been inserting a bunch of PersistingCompositionMarkers and we want to insert a CompositionMarker), Vector::insert() is called to insert a new list:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/editing/markers/DocumentMarkerController.cpp?cl=GROK&gsn=MarkerTypeIndexesCount&rcl=1482337321&pv=1&l=247

Unfortunately this is the wrong operation; insert() shifts all the successor elements so they're now in the wrong positions. So now when we look up the list of PersistingCompositionMarkers, we can't find it since it's in the wrong place, and the markers basically just disappear.