This is because iOS uses REMOVE_ALL_DUPLICATES when asking for history entries that match a particular search query string. The local history db logic is the thing that dedupes matching URLs. And that's before we reach BrowisngHistoryService which is what introduces the concept of a history entry having multiple timestamps.

Then, when the user goes to delete a particular history entry, we only have the timestamps that the local history db gave us. We do create whole day ranges, see ExpireHistoryArgs::SetTimeRangeForOneDay(), but if we deduped across day boundaries, we are not going to delete the older entries. If you then exit edit/search mode, you'll see the older duplicate URL is still in your history, when it seems like it should have been deleted.

Possible solutions would be to switch to deduping only across a single day boundary (which may happen as part of crbug.com/763019), or do the deduping in the BrowsingHistoryService so that we can add the deduped times to HistoryEntry::all_timestamps.