>> Until this is officially fixed I've come up with the following workaround,
>> going off of the details you provided:
>
>> I created a "replace_fixed.el" file in "~/.emacs.d/lisp/" that is
>> replace.el taken from
>> https://raw.githubusercontent.com/emacs-mirror/emacs/emacs-26/lisp/replace.el
>> with
>> the following diff:
>
>> diff --git a/replace.el b/replace_fixed.el
>> index 08feb8e..8280fdd 100644
>> --- a/replace.el
>> +++ b/replace_fixed.el
>> @@ -2227,7 +2227,7 @@ It is called with three arguments, as if it were
>> (isearch-forward (not backward))
>> (isearch-other-end match-beg)
>> (isearch-error nil))
>> - (isearch-lazy-highlight-new-loop range-beg range-end))))
>> + (save-match-data (isearch-lazy-highlight-new-loop range-beg
>> range-end)))))
>
>> (defun replace-dehighlight ()
>> (when replace-overlay
>
>> Then I added the following to my "~/.emacs", restarted my emacs server, and
>> the issue was gone!:
>
>> (load-library "~/.emacs.d/lisp/replace_fixed.el")
>
>> This probably isn't the proper fix, but just thought I'd share in case
>> anyone else is experiencing this and wanted a temporary workaround.
>
> Excellent! To be honest, I was thinking of sending just that workaround
> to you as a temporary patch, but it seems I didn't need to. :-)
>
> That might well be the fix we end up putting into Emacs, but it might
> not be. Sorry we're so slow, here.
I think first we should try to narrow down the source of this match data leak.
Then we could decide what is the best solution. Currently I see no such place
in isearch-lazy-highlight-new-loop that calls external code. OTOH, while
looking at CC-Mode I noticed that it does some matches on before-change hooks.
I could debug it but can't reproduce neither in 26.1 nor in 27, even with -Q -nw.