> I think it's a good interpretation of that docstring.  If needed
> we could additionally tweak the docstring to clarify the behavior.

While testing I found a problem: using 'unhighlight-regexp' ('M-s h u')
displays too long prompt:

  Regexp to unhighlight (default (closure ((case-fold . t) (subexp . 0) (face . hi-yellow) (regexp . foo) t) (limit) (let ((case-fold-search case-fold)) (re-search-forward regexp limit t)))): 

Then I tried to construct a closure *after* adding a plain regexp
to hi-lock-interactive-patterns, i.e. immediately in font-lock-add-keywords.

But this poses another problem: it's not easy to find a closure by regexp
in font-lock-keywords for removing a keyword by font-lock-remove-keywords
in 'unhighlight-regexp'.

I tried the patch below, and sometimes it works, but I know
it's horribly ugly, and it's a wrong direction to search the regexp
in the lexical environment of a closure.

Maybe then better to add an intermediate mapping to hi-lock
like there is in isearch: isearch-message vs isearch-string,
where isearch-message is user-facing representaion,
and isearch-string contains internal data.

This could help to solve another existing problem of using
hi-lock from isearch in char-fold mode, where unhighlight-regexp
displays unreadable prompt too:
  Regexp to unhighlight (default \(?:ḟ\|[fᶠḟⓕｆ𝐟𝑓𝒇𝒻𝓯𝔣𝕗𝖋𝖿𝗳𝘧𝙛𝚏]\)):