Thank you for your PR. Please confirm two points.
(This review was created by Claude Opus 4.6 with 1M context)

1. tpr_set_by_termresponse should be TRUE

File: src/term.c (init_term_props)

    term_props[TPR_DECRQM].tpr_set_by_termresponse = FALSE;

TPR_DECRQM is set to TPR_YES inside handle_version_response() (i.e., based on the DA2 response), so tpr_set_by_termresponse should be TRUE, not FALSE.

When tpr_set_by_termresponse is FALSE, init_term_props(FALSE) (called during terminal re-initialization) will NOT reset TPR_DECRQM, which means a stale value from a previous terminal could persist.

For reference, TPR_CURSOR_STYLE, TPR_CURSOR_BLINK, TPR_UNDERLINE_RGB, and TPR_MOUSE — all of which are set in handle_version_response() — have tpr_set_by_termresponse = TRUE.

2. GNU screen consideration

File: src/term.c (handle_version_response)

The xterm fallback block (where term_props[TPR_MOUSE].tpr_status is TPR_UNKNOWN) sets TPR_DECRQM = TPR_YES unconditionally. GNU screen (arg[0] == 83) matches an earlier branch and doesn't reach this fallback, so it won't get TPR_YES — which is probably correct since GNU screen likely doesn't support DECRQM. Just want to confirm this is intentional.

Here are additional review comments.
(Supported by Claude Opus 4.6 with 1M context)

1. Missing TPR_DECRQM for PuTTY / SecureCRT

File: src/term.c (handle_version_response, version == 136 branch)

The PuTTY branch (arg[0] == 0 && version == 136) and SecureCRT branch (arg[0] == 1 && version == 136) don't set TPR_DECRQM. PuTTY supports DECRQM, so it should probably get TPR_YES. Without it, TPR_DECRQM stays TPR_UNKNOWN and DECRQM sequences won't be sent.

2. Missing TPR_DECRQM for libvterm / Konsole

File: src/term.c (handle_version_response, version == 100 || version == 115 branch)

The libvterm/Konsole branch doesn't set TPR_DECRQM either. Konsole supports DECRQM. For libvterm (used inside Vim's :terminal), it may not be needed, but the two share the same branch — might need to distinguish them or add a comment explaining why it's left as unknown.

3. arg[1] >= 2500 branch covers a wide range of terminals

File: src/term.c (handle_version_response)

if (arg[1] >= 2500)
{
    term_props[TPR_UNDERLINE_RGB].tpr_status = TPR_YES;
    term_props[TPR_DECRQM].tpr_status = TPR_YES;
}

This matches Gnome terminal (1;3801;0, 1;4402;0, 1;2501;0), xfce4-terminal (1;2802;0), and potentially other terminals. Do all of them handle DECRQM properly? The comment says "Assuming any version number over 2500 is not an xterm", which is quite broad.

4. need_flush and DECRQM sending moved outside #ifdef FEAT_TERMRESPONSE

File: src/term.c (handle_version_response)

The original send_decrqm_modes() was called inside #ifdef FEAT_TERMRESPONSE in vim_main2(). In the new code, the DECRQM sending and need_flush / out_flush() are placed outside the #ifdef FEAT_TERMRESPONSE block. If DECRQM sending depends on the termresponse feature, it should stay inside the #ifdef.

5. Guard termcap_active && cur_tmode == TMODE_RAW removed

File: src/term.c

The original send_decrqm_modes() had:

if (termcap_active && cur_tmode == TMODE_RAW)
{
    // send DECRQM ...
}

The new code in handle_version_response() sends DECRQM without this guard. If it's guaranteed that handle_version_response() is always called in raw mode, a brief comment noting that would be helpful.

hm, this causes quite a few test failures. Let me re-trigger CI again.

hm, this causes quite a few test failures. Let me re-trigger CI again.

Should be fixed

there still seem to be some screen dump failures :(

there still seem to be some screen dump failures :(

I'll try fixing them when I can (soon hopefully), it is exam season for me :/

no worries, take your time and good luck for your exams 🤞

@64-bitman I'll take over this matter. Please leave this PR as is.
You should focus on the exam 👍