rl_complete(0, '?') should never insert into the line buffer

[Pip Cet]

I am writing a readline application which, like probably most
nontrivial applications, wants to enable completion but is unable to
exhaustively determine all possible words that can be validly entered
at point.

So the completion function just generates a few likely words. That
works fine. Sometimes it generates a single likely word. That also
works fine: the single word isn't usually inserted until rl_complete
is called with the appropriate argument.

What doesn't work fine is extending the word not to match the
completion, listing possible completions with rl_complete(0, '?'),
removing the suffix which conflicts with the completion, and listing
possible completions again. When I do that, the single completion
suggestion is automatically inserted at point.

Since my application lists completions automatically quite frequently,
I'm running into the above. If the only explicitly-suggested
completion for "x" is "xyz", then entering the key sequence

x x BACKSPACE x x

with automatic completions before and after the BACKSPACE, will result
in the line buffer showing "xyz xx". The expected output is "xxx".

It's this code in complete.c:

    case '?':
      /* Let's try to insert a single match here if the last completion failed
     but this attempt returned a single match. */
      if (saved_last_completion_failed && matches[0] && *matches[0] &&
matches[1] == 0)
    {
      insert_match (matches[0], start, matches[1] ? MULT_MATCH :
SINGLE_MATCH, &quote_char);
      append_to_match (matches[0], delimiter, quote_char, nontrivial_lcd);
      break;
    }

The code in question seems extremely questionable to me: '?' is meant
to LIST completions (non-destructively), not insert a completion.
Again, with most applications, it's valid and useful to continue
typing in something that doesn't match a completion.

Let's just remove this special case: it's undocumented, violates the
distinction between text-modifying and non-destructive calls of
rl_complete, it's useless for applications where non-completed words
are still valid input, and it complicates things.

This bug affects bash: if there is a single file in the current
directory named "xyz", then:

e c h o SPACE a SPACE > SPACE x x ESC ? BACKSPACE ESC ? RET

will result in the file "xyz" being overwritten, rather than a new
file called "x" being created. This also contradicts the bash
documentation.

Thanks,
Pip