bug#40152: 27.0.90; icomplete vs recursive prompts

[Kévin Le Gouguec]

OK, I think I have a simpler reproducer.

>From emacs -Q:

#+begin_src elisp
(icomplete-mode)
(setq enable-recursive-minibuffers t)
(completing-read
 "Prompt #1? "
 (lambda (&rest _args)
   (read-string "Prompt #2? ")
   (list "foo" "bar" "baz")))
#+end_src

Current result:
1. prompt #1 appears,
2. I type in a letter, say "x",
3. prompt #2 immediately appears, hijacking prompt #1,
4. I type in another letter, say "y",
5. prompt #1 returns, hijacking prompt #2; the "x" I typed is there,
6. I type in another letter, say "z",
7. prompt #2 returns, hijacking prompt #1; the "y" I typed is not there.

Expected result:
1. prompt #1 appears,
2. I type in a letter, say "x",
3. prompt #2 immediately appears, hijacking prompt #1,
4. I type in another letter, say "y",
5. *PROMPT #2 REMAINS* until I hit RET/C-j/C-g…
6. prompt #1 returns; the "x" I typed is there.

(If icomplete-show-matches-on-no-input is set, I guess I'd expect Emacs
to go straight to step 3, with prompt #1 empty on step 6.)

To summarize my previous messages:

- In addition to this synthetic recipe, I have two fairly annoying
  reproducers:

    1. xref-find-definitions bounces back between the identifier prompt
       and the TAGS table prompt (when there are no tags at point and
       xref falls back to the etags backend).

    2. TRAMP bounces back between the filename prompt and the
       .authinfo.gpg passphrase prompt.

- Even after hours of debugging, I still feel out of my depth with the
  completion code; I'd really appreciate some help.  I don't mind
  debugging some more, but at this point I'd need a clue where to look.

(Since I feel like my synthetic reproducer is small enough, I'm boldly
CC'ing folks I imagine to be the most familiar with the completion
framework and/or icomplete; I apologize for the forwardness.)