tmux OSC 52 clipboard silently fails after reattaching session to terminal without Ms capability

Goal

Maintain consistent system-clipboard access via OSC 52 when a tmux session is reattached to different terminal emulators, some of which declare the Ms terminfo capability and others that do not.

Constraints and uncertainty

tmux 3.2–3.4 uses the static Ms entry in the attached terminal’s terminfo to decide whether to forward OSC 52 sequences when set-clipboard external is set. No runtime negotiation or capability probe occurs at attach time. If a session created under a terminal that advertises Ms (e.g., Kitty, WezTerm, iTerm2) is reattached to a terminal lacking the capability (e.g., a minimal xterm or a distribution terminfo missing the entry), tmux silently drops the escape sequences. The user receives no warning, fallback, or error message, and key bindings that invoke copy-pipe or rely on the built-in clipboard integration appear to work but leave the system clipboard unchanged.

Terminfo databases shipped with common distributions may omit Ms even for terminals that support OSC 52, producing false negatives. Nested tmux sessions add a further requirement: both inner and outer tmux must have allow-passthrough on (default since 3.3) and the outer terminal must honor the passthrough.

Questions

1. Is there a supported way to detect at runtime whether the currently attached terminal will honor OSC 52, so that scripts or key bindings can fall back to an alternative (e.g., copy-pipe to xclip/wl-copy) without user intervention?
2. Can tmux be configured to emit a visible warning or status-line indicator when set-clipboard external is active but the attached terminal lacks Ms?
3. Does any tmux version ≥3.2 provide a hook or callback that fires on client-attach, allowing a custom capability check before clipboard operations are attempted?