>>>>>> OTOH we should probably try and change the `key` arg to use the new
>>>>>> key-list format expected by `describe-key` (i.e. a list of (SEQ
>>>>>> . RAW-SEQ) pairs).
>>>>>
>>>>> `gnus-article-describe-key` just passes down the value
>>>>> that `read-key-sequence` returns.
>>>>
>>>> I know.  This is the old calling convention of `describe-key`; we
>>>> should move to the new one.
>>>
>>> Is seems everything is covered by this patch:
>>
>> So this is pushed now.
>
> Thanks, and sorry I didn't get to it earlier.  FWIW, it does look good,

Oh, another regression:

 C-s                 ;; isearch-forward
 C-h k               ;; isearch-describe-key

then typing any key to describe in isearch-mode
leaves isearch in a broken state: it displays the
search prompt, but no isearch indicator on the mode-line.
So something exits isearch.  Adding a breakpoint
in isearch-done reveals this backtrace:

  isearch-done()
  isearch-mouse-leave-buffer()
  mouse-minibuffer-check(19)
  mouse-set-point(19)
  help--analyze-key("\23" [19] nil)
  describe-key((("\23" . [19])))
  funcall-interactively(describe-key (("\23" . [19])))
  isearch-describe-key()
  funcall-interactively(isearch-describe-key)
  command-execute(isearch-describe-key)

I don't know if more functions using describe-key are broken,
but copying the same code from gnus-article-describe-key
that gives the buffer argument to describe-key fixes this.
I have no idea for a better way to avoid such problems.

More precautions are added to this patch:
when isearch-mouse-commands contains isearch-describe-key,
isearch-mouse-leave-buffer won't leave isearch-mode.

Also to avoid a broken state, isearch-update
should be used only when isearch-mode is active: