> It seems to me a high-level view of completion-no-auto-exit is to allow
> code outside of choose-completion and choose-completion-string to finish
> the completion selection process.  Presently, this flag does inhibit
> closure of the minibuffer when choosing a completion but it does not
> inhibit closure of the list of completions if '?' has been used.  I think
> the two are connected and that whatever external code is used to utilize
> the finalized completion should also handle the closure of the completion
> window.

Currently I'm developing a patch (attached below) that allows to type
‘M-0 RET’ on a completion to insert it to the minibuffer, and quit the window
without exiting the minibuffer.

So to keep backward-compatibility of completion-no-auto-exit,
its behavior should not be changed.

Then there are two options: create a new variable, e.g.
completion-no-auto-quit - to not quit the completion window.

Or better to support a new value of the existing variable
completion-no-auto-exit, e.g. 'no-quit-window'.

> This can be accomplished by simply wrapping the call to 'quit-window'
> within 'choose-completion' with an '(unless completion-no-auto-exit...)'
> like so:
>          (unless completion-no-auto-exit (quit-window nil (posn-window
> (event-start event))))
>
> Please consider adding this as a quick fix.  Then packages like Hyperbole
> which requires 2 clicks/presses to finalize a completion selection could
> use choose-completion without having to replace the whole function.

Please describe the use cases in more details.  When I tried to use
the aforementioned condition, then after selecting a completion,
the selected window is not switched to the minibuffer window.
The completion window says selected.  I'm not sure if this is what is needed.
It seems after selecting a completion without quitting the completion window,
it's expected that the minibuffer window should be selected.