`bind -x '"...": setsid kill -2 $$'` works but `bind -x '"...": kill -2 $$'` does not
I'm stumbling over a behavior in bash that I don't 100% understand. The following doesn't work as expected:
bind -x '"\ex": kill -SIGINT $$'
I would expect this to behave pretty much identical to pressing Ctrl-C, which in a normal terminal in canonical mode would send a SIGINT to the foreground process group of the session associated with the controlling terminal, which is in the case of readline in bash is handled by an appropriate signal handler that aborts the current readline buffer and reprints the prompt. Because of stty echoctl, we should also see a ^C being printed by the terminal itself.
However, this is not what happens. Instead, when I type \ex (Alt-x or Meta-x), it deletes the current PS1 prompt string, does NOT print ^C, moves to a new line, and then prints a new PS1 prompt string. Visually, it looks like the current line was completely erased (basically what printf '\033[2K' would do) and then a new line is created. Running it multiple times creates a lot of empty whitespace. Functionally, it's identical to Ctrl-C, though, which makes sense.
The weird thing is, if I run the kill -SIGINT command from another terminal, OR I adjust the command to be setsid kill instead of just kill (I know that this calls /bin/kill instead of the bash builtin kill, but that's irrelevant to the matter), then it suddenly works exactly as expected, identical to pressing Ctrl-C.
Can someone explain exactly what is going on? Adding stty sane or stty echo echoctl before the kill didn't help, unfortunately. My guess is that in the "bind -x" execution context, the terminal characteristics are set to -echo -echoctl (and maybe some more), but then why doesn't stty sane/stty echo echoctl help it?