Perhaps as simple as adding help modes to hi-lock-exclude-modes?  It looks like hi-lock mode exclusion logic might need a little improvement to honor derived modes.

On Sun, Mar 2, 2025 at 12:33 PM Daniel Colascione <dancol@dancol.org> wrote:
Stefan Kangas <stefankangas@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Daniel Colascione <dancol@dancol.org>
>>> Date: Sun, 02 Mar 2025 10:49:15 -0500
>>>
>>> >From emacs -Q, M-x global-hi-lock-mode, then C-h m, then quit the help
>>> buffer, and type C-h m again.  You'll get prompted about whether you
>>> want to apply the hi-lock patterns in the help buffer.  And then,
>>> because for some reason we don't actually clear the help buffer but just
>>> narrow it to what we want, the next time you ask for help, even on
>>> something unrelated to hi-lock (e.g. progn), hi-lock will ask you
>>> whether you want to apply hi-lock patterns.
>>
>> That's the default of hi-lock-file-patterns-policy, no?  IIUC, hi-lock
>> asks this question for every file you visit, if it finds the patterns
>> there.
>>
>> Or what am I missing?
>
> The default is `ask`, which is documented to mean:
>
>     If `ask', prompt when patterns found in buffer; if bound to a
>     function,
>
> but `(describe-function 'progn)` doesn't describe any patterns.
>
> (FWIW, I'm very much not a fan of this default.  If the user didn't want
> them highlighted, she would not have turned on `global-hi-lock-mode`.)

Isn't the idea that hi-lock patterns can contain arbitrary font lock
keywords which can run arbitrary code?