Allow binding Control+Backspace (at least in Windows)

One of my main usability issues with xonsh that's relying on your prompt toolkit is that I can't remap a very common key combo — ControlBackspace — to delete a previous word

There is already a similar issue that was closed with a reference to your comment; and as far as I understood, with the relevant code with some additional justification here:
https://github.com/prompt-toolkit/python-prompt-toolkit/blob/d6ac8be0791184d87262d5a759b11664dcdbf110/prompt_toolkit/input/ansi_escape_sequences.py#L58

# Vt220 (and Linux terminal) send this when pressing backspace. We map this
# to ControlH, because that will make it easier to create key bindings that
# work everywhere, with the trade-off that it's no longer possible to
# handle backspace and control-h individually for the few terminals that
# support it. (Most terminals send ControlH when backspace is pressed.)
# See: http://www.ibb.net/~anne/keyboard.html
"\x7f": Keys.ControlH,

Question 1

Is there any chance to revert this bundling of two keys into one key code?
The blog mentioned above as part of the rationale for this seems to have changed its approach and (though I'm not certain) to now favor separating backspace and control-h so that "^H ... can be used by applications" (which I assume would allow mapping ControlBackspace separately from Backspace)

In my previous attempt at working around the problem, I put most of my effort in trying to map all keys to suit xterm's vt100 emulation.
However, I now propose another way to deal with the problem.
This basically means getting xterm to work with the consoles' default settings: [<---] will do ASCII DEL (0x7F, or ^?), and [Delete] will do "\e[3~".
This way ^H is not used for any terminal specific functions, it can be used by applications.

Or at least make this optional/configurable so that a user can decide whether the trade-off is worth it?

Question 2

Regardless of the general solution, is it possible to achieve the same in Windows, where b"\x7f" is already mapped to Keys.Backspace, not Keys.ControlH?
https://github.com/prompt-toolkit/python-prompt-toolkit/blob/d6ac8be0791184d87262d5a759b11664dcdbf110/prompt_toolkit/input/win32.py#L148

I'm not really sure how exactly all these mappings work and what the potential downsides are, but I've made just a couple of very minor changes in this fork

• Added ControlBackspace = "c-backspace" to keys.py
• Replaced b"\x7f": Keys.Backspace, with Keys.ControlBackspace in win32.py

...and I'm able to map ControlBackspace to delete previous word just fine in xonsh (using this function with the key changed to ControlBackspace)

Alternatively, leaving the b"\x7f" as is and adding a function similar to Turn 'Space' into 'ControlSpace' when control was pressed. also seems to work:

 # Turn 'Backspace' into 'ControlBackspace' when control was pressed.
if ((ev.ControlKeyState & self.LEFT_CTRL_PRESSED or ev.ControlKeyState & self.RIGHT_CTRL_PRESSED)
    and result and result.key == Keys.Backspace
):
    result = KeyPress(Keys.ControlBackspace, "")

Are there any major issues with this simple addition of ControlBackspace that would prevent adding this change to your toolkit?

Review prompt_toolkit/keys.py, prompt_toolkit/input/win32.py, and prompt_toolkit/input/ansi_escape_sequences.py, starting with the existing Backspace and ControlH mappings. Determine how Control+Backspace can be represented without breaking existing terminal behavior, then verify that it can be bound separately on Windows and that current mappings remain intact.