menu-select widget interacts badly with interactive style

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

I just stumbled upon a bit of confusing behavior that probably warrants
a mention somewhere ... I'm just not sure where.

I have a widget defined with "#compdef -k menu-select ...".  This bypasses 
_main_complete for that widget because of the implementation of #compdef 
in compinit, even though menu-select itself is mapped onto _main_complete.  
Most of the time this is OK.  (Evidently this is something I should be 
doing with _generic instead?)

However, if I also use "zstyle ':completion:*' menu select interactive" 
things get interesting.

With this setting, since none of the values is "yes", the automenu rules
are in effect and normal TAB completion produces a listing on the first
TAB and enters menu selection (with interactive mode) on the second TAB.
So far this is all as expected.

When I invoke my own widget before having done any other completions, it 
does not start interactive selection, because _main_complete is never 
called -- but after I've entered menu selection through TAB completion, 
_main_complete leaves the MENUSELECT et al. control variables set.  Thus 
the *next* time I invoke my menu-select widget, that also starts up in 
interactive mode.  (I presume the same would apply to search mode.)

It was quite disconcerting for a while there not being able to predict 
whether I was going to get interactive mode or not, before I figured out
what was going on.

Another less urgent factor is that the SPACE key breaks out of interactive 
menu selection even when there are spaces in some of the possible matches.  
In some cases this makes it impossible to disambiguate the match, and one 
is forced to (a) remember not to type space because it'll stop completion 
and perform self-insert, and (b) use down-history et al. to begin normal 
menu selection and navigate to the desired match.