I have GNU nano 8.4 on my system. Upon investigation, in default configuration:

• Control-Backspace deletes the last character, same as Backspace.

• Control-Delete reverse-deletes a word.

• Alt-Backspace deletes the last word. This might be what you want.

• Alt-Delete deletes the entire line.

I think that it's probably because absent some kind of unusual extension, terminals normally send 0x08, the Backspace character, same as Control-H, for Control-Backspace.

On my system, in bash, using foot, Control-V Control-H shows ^H. So it's sending ASCII 0x8, the Backspace character.

Control-V Control-Backspace shows ^H. Ditto.

Control-V Backspace shows ^?. It's sending the Delete character, ASCII 0x7f.

Control-V Del shows ^[[3~. It's sending an escape sequence.

Back in the day, some people had their terminals set to, when you hit Backspace, send either the Backspace character or the Delete character. Not a problem I've run into for some years, but I'd guess that nano probably has that behavior by default, treating both 0x7f and 0x8 as hitting the Backspace key, so as not to break on systems like that.

EDIT: I'd also add that Alt-Backspace (well, M-DEL in emacs parlance) is also what emacs uses for "delete word", so a lot of software that uses readline, like bash, will also normally work that way out of box.

EDIT2: If you want to investigate ways to have terminals recognize more key combinations (so that you aren't sending the same sequence for both Control-H and Control-Backspace and want to get down and dirty aiming to configure software to use different bindings for those different keystrokes), IIRC the kitty virtual terminal emulator has been exploring extensions, and some terminal emulators have implemented some of those extensions.

searches

Yeah.

https://terminfo.dev/extensions/kitty-keyboard-protocol

The Kitty keyboard protocol solves fundamental ambiguities in traditional terminal input handling. Legacy terminals cannot distinguish between Ctrl+I and Tab, Ctrl+M and Enter, or Escape and the start of an escape sequence — they all produce the same byte sequences. The protocol also enables key-release events and distinguishes between different modifier key presses (left vs. right Shift). Applications opt in with CSI > flags u, where flags is a bitmask selecting reporting modes: disambiguate keys (1), report event types (2), report alternate keys (4), report all keys as escape sequences (8), and report associated text (16). Keys are reported as CSI unicode-key-code : shifted-key : base-layout-key ; modifiers : event-type u. Adopted by Ghostty, WezTerm, foot, and rio. The protocol is progressive — applications can request only the features they need, and terminals report which flags they support.

That being said, I would guess that a lot of programs that run in the terminal won't be set up out of box to rely on Kitty protocol extensions.

EDIT3: Also, I don't think that fbcon (the default Linux kernel framebuffer console) or fbterm (the userspace virtual terminal), one of which you'd probably use if you switched out of Wayland/X11, presently support Kitty input extensions, so if you rig up programs to rely on said extensions, you won't have those keys available in the plain ol' Linux console.