It seems that this is a serious problem with Hits based search. An application deleting returned hits as in this case will actually get "holes" in the returned docs, every time getMoreDocs() is internally invoked.
For instance, say all docs match, and the app deletes doc 50. Hits 0 to 99 are ok, they will contain docs 0 to 99. But because of the deletion, hit 100 will be doc 101, i.e. doc 100 was skipped.
Fixing this behavior is possible in the Hits class if only hits are deleted. I.e. if, while getting hit n, hits m where m<=n are deleted. But if a higher doc is deleted, a doc that would be seen later, after more internal calls to getMoreDocs(), things get more messy, and an ArrayIndexOutOfBound exception can be caused, as in this bug.
Note that the latter case can also happen if another thread deletes such a "front" hit doc.
I think the proper exception for the latter case is ConcurrentModificationException, and Hits should be changed to distinguish between the two.