Steps to reproduce

1. SSH into Windows machine using PowerShell
2. Open vim 9.1
3. Enter insert mode
4. Try to use arrow keys
5. Notice that arrow movements register irregularly, often only after pressing another key

Expected behaviour

Arrow keys should move cursor immediately in insert mode, as they do in vim 9.0.

Version of Vim

9.1.857

Environment

Operating System: Microsoft Windows 10.0.19045 Build 19045
Terminal: xterm-256color
Shell: PowerShell 7.4.6

Logs and stack traces

Old (working) version:

VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Jun 28 2022 12:30:17)
MS-Windows 32-bit console version

New (problematic) version:

VIM - Vi IMproved 9.1 (2024 Jan 02, compiled Nov 11 2024 22:33:33)
MS-Windows 64-bit GUI/console version with OLE support

Comparing :set termcap output between versions reveals different terminal sequences:

OLD:

t_8b=^[|48;2;%lu;%lu;%lum
t_8f=^[|38;2;%lu;%lu;%lum

NEW:

t_8b=^[[48;2;%lu;%lu;%lum
t_8f=^[[38;2;%lu;%lu;%lum
t_8u=^[[58;2;%lu;%lu;%lum

Possible root cause:

In term.c, there's a comment and code that automatically sets these sequences:

// There is no good way to detect that the terminal supports RGB
// colors.  Since these termcap entries are non-standard anyway and
// only used when the user sets 'termguicolors' we might as well add
// them.  But not when one of them was already set.

This automatic setting of non-standard terminal sequences appears to be putting the terminal in a state that affects arrow key handling.

Workarounds:

Running :!reset fixes the issue temporarily.

I looked at runtime/doc/todo.txt:

Vim internal, but there should be a terminfo entry for these:
- t_8f	set foreground color (R, G, B) in printf() format
- t_8b	set background color (R, G, B) in printf() format
- t_8u	set underline color (R, G, B) in printf() format

When I use the older format using printf format, like this:

let &t_8f = "\<Esc>|38:2:%lu:%lu:%lum"
let &t_8b = "\<Esc>|48:2:%lu:%lu:%lum"

The immediate problem with arrows in insert mode goes away, but it remains when I use the new sequence, which changes | for [. So in this case, it seems that just changing the format alone will not be enough to fix the issue.

The automatic setting of RGB sequences should perhaps be disabled by default, requiring explicit opt-in, as sending these non-standard sequences is causing real usability issues in common terminal configurations. At minimum, there should be a way to disable this behavior without having to explicitly clear the sequences.

The current approach of "sending sequences and hoping for the best" breaks basic editing functionality in scenarios where the terminal doesn't handle these sequences gracefully.