>> > I think the problem is not that we remove the highlight and add it
>> > anew, the problem is that there's a redisplay cycle in between the
>> > removal and the following addition.  The fact that setting
>> > lazy-highlight-initial-delay alleviates the problem to some extent,
>> > but still leaves the flicker tells me that there's a call to sit-for
>> > or some such somewhere in the code that processes replacements, and
>> > the removal and addition of the highlight are on two different sides
>> > of that sit-for call.  One possible solution would be to remove the
>> > highlight and add it without triggering redisplay, then I'd expect the
>> > flicker to go away.
>> >
>> > Does this make sense?
>>
>> This feature is called _lazy_ highlighting where _lazy_ implies that it's
>> intended to highlight matches much later after a lot of redisplay cycles.
>
> You could still leave the "lazy" part, if you both remove and re-add
> the overlays after the idle delay.  IOW, the important thing is not to
> have redisplay between removal and addition of the highlight.

That's an option too, and here is the tested patch (it sets
lazy-highlight-max-at-a-time to nil to avoid redisplay between
lazy iterations):