Well it seems quite obvious now that I simply overlooked the fact that
quoting a list results in its elements not getting evaluated. I would argue
that, although there might be no real bug in the doc, the doc still somehow
helped me to overlook this fact. I think backquoting is not very much a
hassle, but it would be nice to get reminded about it for when using the
(kbd ...) construct. Of course if the (kbd "j") would not have worked I
would have been less confused and maybe had found the mistake myself, but
because that one did work it appeared to me to be a bug. Anyway, I think a
simple change/addition in the docstring and/or the examples in section
23.3.3 of the elisp manual could help make things clearer.

On Sat, 26 Sep 2020 at 18:05, Drew Adams <drew.adams@oracle.com> wrote:

> > > The cons ((kbd "C-n") . 'foo) is exactly such a
> > > (KEY . BINDING) pair - both KEY and BINDING are
> > > suitable arguments for `define-key'.
> >
> > Is it?
> >
> > ELISP> (define-key global-map '(kbd "C-n") ''foo)
> > *** Eval error ***  Wrong type argument: arrayp, (kbd "C-n")
>
> I get your point.  I guess maybe there are two ways
> to read the doc string.
>
> The most _useful_ behavior for users, IMO, is for
> `define-minor-mode' to allow expressions in arg
> KEYMAP (when it's such a list) that correspond to
> what a user writes in `(define-key ...)'.
>
> Is that particular list form of KEYMAP intended
> mostly for programmatically supplying such a list,
> or for users to write such a list?
>
> If the former, why is it needed/helpful at all,
> since code can just as easily create a keymap arg.
> If the latter, it gives users an easy way to write
> key bindings directly for `define-minor-mode'.
>
> I hadn't even paid attention to the existence of
> such a form for the KEYMAP arg.  But it looks like
> it could be handy for users to write - IF the sexp
> to write is simple and straightforward.
>
> If users instead need to use backquote syntax or
> jump through other hoops to write such a KEYMAP
> sexp, then what's the point - what's the use case?
>
> Maybe there _is_ a programmatic use case.  If so,
> what is it?
>