mouse wheel events - why an extra <nil>?

["Drew Adams" <drew.adams@oracle.com>]

This is about mouse wheel events, on Windows at least.  (Dunno if it is
platform-dependent, but Emacs on Windows does handle wheel events differently.)

Consider this:

(defcustom foo-keys (list [nil (control wheel-up)] ; A
                          [(control wheel-up)])    ; B
  "..." :type '(repeat sexp))

(dolist (key  foo-keys)
  (define-key minibuffer-local-must-match-map key 'toto))

It seems to be the case that both A and B are needed in order to bind the wheel
action to `toto'.  (And this is so regardless of whether modifiers such as
`control' are present.)

I would have expected only B to be needed.  That is, I would expect the wheel
event/key to always be <C-wheel-up>, but it seems to be the case that: (a) first
it is <nil> <C-wheel-up> and thereafter just <C-wheel-up>.  I don't understand
why.

That is, if only B is defined then the wheel action never calls `toto' - a
message says that <nil> <C-wheel-up> is undefined.  (What is that <nil>?  Where
is it from?)

And if only A is defined then only the first C-wheel-up of a sequence calls
`toto'.  Subsequent C-wheel-ups do nothing - a message says that <C-wheel-up> is
undefined.

This is most clearly seen if <C-wheel-up> is bound in the `global-map' to some
other command, say `titi'.  If B is removed, so the only minibuffer binding for
a C-wheel-up action is (define-key minibuffer-local-must-match-map [nil (control
wheel-up)] 'toto)), then the first C-wheel-up calls `toto' and the second and
subsequent C-wheel-ups call `titi' (the `global-map' binding).

I'd like to understand this.  I don't notice this behavior for a global wheel
binding (i.e., outside the minibuffer).  For instance, repeated C-wheel-ups
always call `titi', and there is no need for an additional global binding to
`titi' of [nil (control wheel-up)] - just binding [(control wheel-up)] suffices.

Is there a bug here perhaps?  If not, can someone please enlighten me as to what
is going on?  The doc regarding mouse events, and wheel events in particular,
does not cover this at all, and the code in mwheel.el is likewise no help here.

(One other bit of info that might be relevant, though I doubt it, is that I'm
using a standalone minibuffer frame.)