1) Indexed cursors need not be considered in ClientCursor::aboutToDelete(). Indexed cursors recover their position in recoverFromYield() so advancement on document deletion is unnecessary. Currently, matching indexed cursors are prepared for and recover from yielding at each deletion advancement, which may cause a substantive performance penalty in some cases due to unnecessary btree lookups. Indexed cursors currently recover their positions after key modifying document updates, which do not trigger ClientCursor::aboutToDelete() or other explicit advancements. This means indexed cursors should already correctly handle a key deletion triggered by a document deletion. At this time indexed ClientCursors should continue to maintain valid refLoc() values if changes to one of the btree bucket invalidation implementations are to be avoided (see SERVER-4575).

2) Cursor based write operations (update and delete) currently (with the SERVER-5198 fix) advance to a document other than the one to be modified before performing a modification. This could potentially result in a significant number of iterations through adjacent keys being performed without yielding, which in the update case may be particularly significant because with delete the keys will all be removed without yielding while with update they may not be. The following alternative implementation may be used: If the cursor is unindexed, advance it to the next iterate; otherwise do not advance before modification. This implementation will handle $or clause transitions properly, and indexed cursors will be handled properly by recoverFromTouchingEarlierIterate(). This alternative implementation requires more (currently correct) assumptions than the current one, for example that a $or query will not traverse another cursor after an unindexed cursor. While more efficient in some cases, the implementation would be a bit more delicate.