Now I see the recent change to master (Dec 9). I'd add that pretty much every other "curses" based app that supports mouse activity defaults to mouse on, though. Not sure why Emacs's recent default to on should be surprising. People would be surprised that the mouse doesn't work. That Terminal.app also steals command keys from those apps is also not a surprise.

On Mon, Dec 16, 2024 at 2:58 PM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Ship Mints <shipmints@gmail.com>
> Date: Mon, 16 Dec 2024 14:20:40 -0500
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>       Eli Zaretskii <eliz@gnu.org>, Jared Finder <jared@finder.org>, 74833@debbugs.gnu.org
>
> I think about it like this: if Terminal.app successfully passed through all its keys (which it can be configured to
> do), Command-C would appear in Emacs as M-c but it doesn't. Does it surprise you that Command-P offers
> the print dialog when Emacs is running in the terminal? This is no different than Command-C. That
> Terminal.app supersedes Emacs is not an Emacs problem, it's Terminal's problem. This feels like
> documentation issue not something to cure with default Emacs configuration.
>
> Other terminal applications like iTerm or WezTerm can be programmed similarly to pass through all keys
> that you want them to with modifiers, but by default, they don't. These can't be Emacs's problem either.
> Same with Emacs run via ssh with tmux on the other side. That's a "default" set of features offered on many
> systems and their configuration is not Emacs's problem.

I see your points, but the fact remains that our enabling of
xterm-mouse-mode triggered these problems where previously there were
none.

> This issue sounds like an "impedance mismatch" to my ears, even if it surprises some users and requires
> some configuration depending on your specific goals and should perhaps be better documented.

If a default behavior needs documentation to explain it, it is usually
a sign of a not-very-good default, IME.