I haven't confirmed this behavior with a test, but it looks like the following sequence of events may be possible:

1) a client cursor points to a btree entry with key 'a' with disk loc X and is yielding or awaiting getMore
2) the object at loc X is modified in place so as to not contain key 'a'
3) the object at loc X is removed

As part of 3), clientcursor's aboutToDelete() will expect to find a cursor pointing at btree node <'a',X> and call checkLocation() on that cursor. Because the btree key has been removed, checkLocation() will advance to the next key past the expected one. If this key has a refLoc other than X (which is quite likely), aboutToDelete() will log a warning and advance the cursor again anyway, even though it should not advance because the btree key is pointing at a different record location.