Collection notification indices: correct or not?

I just happened upon something that I don’t understand regarding receiving collection notifications. The documentation states that deletes and insertions should be handled first. Presumably, this is because the indices of the objects in the results could change compared to the prior results before the write. I’ve just come across an issue where an object is deleted from the results, and all of the other results are modified. However, the indices for the modifications are not what I would expect:

(lldb) po deletions
▿ 1 element

  • 0 : 38

(lldb) po insertions
0 elements

(lldb) po modifications
▿ 41 elements

  • 0 : 0
  • 1 : 1
  • 2 : 2
  • 3 : 3
  • 4 : 4
  • 5 : 5
  • 6 : 6
  • 7 : 7
  • 8 : 8
  • 9 : 9
  • 10 : 10
  • 11 : 11
  • 12 : 12
  • 13 : 13
  • 14 : 14
  • 15 : 15
  • 16 : 16
  • 17 : 17
  • 18 : 18
  • 19 : 19
  • 20 : 20
  • 21 : 21
  • 22 : 22
  • 23 : 23
  • 24 : 24
  • 25 : 25
  • 26 : 26
  • 27 : 27
  • 28 : 28
  • 29 : 29
  • 30 : 30
  • 31 : 31
  • 32 : 32
  • 33 : 33
  • 34 : 34
  • 35 : 35
  • 36 : 36
  • 37 : 37
  • 38 : 39
  • 39 : 40
  • 40 : 41

As can be seen, the object at index 38 was deleted. In the modifications index array, this index is missing. But should it be? Object 39 should now be at index 38, so I would not expect there to be a gap in the indices for modifications. Basically, if I loop over the indices for the modifications, I will hit an index-out-of-bounds error when getting to 41.

Any help or insight would be greatly appreciated.