Bash – Erase character with BackSpace on a bash command line

You're giving the keystrokes, but not the readline bindings, this can explain differences in observed behaviour (try bind -p).

The only way I can think of to do exactly what you ask is to use a custom completion function that saves the buffer state, and a separate key binding which invokes a companion shell function to restore it.

In addition to @Mark Plotnick's excellent suggestion to use menu-complete, other readline/bash options are:

• shell-backward-kill-word this removes a "shell word" which in the case of an expanded file or path will be the complete file or path name
• backward-kill-word this removes a "readline word", which in the case of a file or path will be a file or directory name component, including the trailing /
• undo which undoes each change atomically, but this almost certainly requires several attempts to fully remove a complete expansion, this is almost certainly the function you have bound to to ctrl-_ (bash default)
• set-mark and kill-region are lesser used readline features, set-mark marks the current cursor position, and kill-region deletes from the mark to the cursor. This requires you to invoke set-mark (default meta-space) in advance so that you can later use kill-region to delete back to it (no default binding)
• possible-completions (bound to meta-=) which lists the completions without modifying the command buffer

You could also write your own function to modify the input buffer, and bind it to a function (here's one I made earlier) but I don't see how that would be very much better than backward-kill-word in this case.

You can test bindings on the fly without using .inputrc using bash's bind command, e.g.:

bind "\C-o: backward-kill-word"
bind "\C-o: shell-backward-kill-word"

backward-kill-word is the best fit, default binding is metactrl-h. set-mark/kill-region would be better, but I can't think of a neat way to automate the use of this though.

The behavior of C-m, C-i, etc. is implemented by bash, but the fact that they're the same thing as Return, Tab, etc. is due to the behavior of the terminal. All terminals behave like this because all terminals have always behaved like this and it's what applications expect. The interface between a terminal and an application is based on characters (in fact, bytes), not on keys, so keys that don't send printable characters and key combinations have to be encoded somehow. See How do keyboard input and text output work? for more on this topic. See also https://emacs.stackexchange.com/questions/1020/problems-with-keybindings-when-using-terminal

TAB is the tab character in ASCII, and that's the same thing as the Ctrl+I character in ASCII. Likewise for the other keys. Terminals send that character both when the user presses Tab and when the user presses Ctrl+I. Ditto for RET (CR) and C-m, for LFD and C-j (which most keyboards don't have), and for ESC and C-[. There's also BackSpace which sends either C-h or C-?, that's an issue of its own.

The configuration of the terminal (stty settings) can additionally come into play, and this affects some of bash's settings (e.g. after stty erase @, bash will treat pressing @ as BackSpace), but not C-m and C-j to submit the current line.

^[[D is Esc [ D, but with a capital D. If you press Esc [ D, bash sees the Left key, due to the declaration of cursor key escape sequences in the termcap or terminfo database. There's no default binding for Esc [ d (it isn't an escape sequence that common terminals send).