I'm on the latest commit (55772baee1627571c0814cf2d666fb3b963ff591) now.
Unfortunately the bug can still be reproduced on my side.

> FTR, I use setq, not setq-default, and I also do this before
> running the experiment (to avoid unrelated triggers for redisplay):

>   M-x blink-cursor-mode RET
>   M-x global-eldoc-mode RET

> And M-~ after pasting the code which starts the overlays.

Even if I follow these steps when testing, with mode-line-format begin nil,
on
the latest commit, it can still be reproduced.

But I think your patch is doing its work. I did some programming work, and I
feel the chance it happens becomes lower.

Eli Zaretskii <eliz@gnu.org> 于2021年8月15日周日 下午7:21写道：

> > Date: Sat, 14 Aug 2021 12:25:43 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 44448@debbugs.gnu.org
> >
> > > >  Error during redisplay: (mode-line-default-help-echo #<window 3 on
> paren.el>) signaled (quit)
> > >
> > > I'm afraid this is not the truth. If you eval
> > >
> > >     (setq-default mode-line-format nil)
> > >
> > > before step 6, the problem still happens, and there's no error
> messages in the *Messages* buffer.
> >
> > Not here, it doesn't.  If I set mode-line-format to nil in the buffer
> > that visits paren.el, I cannot reproduce the problem anymore.
> >
> > However, as I wrote in my other message, the :eval form in the mode
> > line cannot be the whole story, because we evaluate these forms in a
> > way that should (and does) catch any errors, including quit.
> > Something else is at work here.
>
> I found a few places where we allowed redisplay_window to exit
> non-locally, leaving point in its temporarily wrong position.  This
> should now be fixed on the master branch.  Please test.
>
> Thanks.
>