> That there's some fallout cannot be used as an ultimate argument in
> favor or against some change.

In that case, could you explain what /would/ be a good argument in
favor or against the change I am proposing? As far as I can tell, it
saves people time without any known disadvantages (and with very
little additional complexity -- the patch being about 70 lines of
code), but you don't seem to consider this a good enough argument.
Have I misunderstood something?

> From: Eli Zaretskii <eliz@gnu.org>
> Date: Jan 15, 2019, 11:26 AM
>
> > From: Radon Rosborough <radon.neon@gmail.com>
> > Date: Tue, 15 Jan 2019 11:43:39 -0700
> >
> > > From: Eli Zaretskii <eliz@gnu.org>
> > > Date: Jan 15, 2019, 10:19 AM
> > >
> > > I'm saying that we should hear the complaints first and devise
> > > the solution only after that.
> >
> > If we wait until Emacs 27.2 to fix the complaints, then it will
> > already be too late to do anything useful.
>
> That was the situation before the recent changes, and we still made
> those changes.

I don't see why this would be an argument against the change I am
proposing. The recent changes were useful, which is why we made them,
but they would have been even /more/ useful if we had made them
earlier (before everyone's init-files got changed). The situation is
the same here. Maybe it would still be helpful to make these changes
in Emacs 26.2, but they would be a lot /less/ helpful at that point in
time.

> So maybe the right solution is to make that variable public instead.

Maybe. But this seems like a strictly inferior solution from the
perspective of user experience, since it still results in users being
shown superfluous warnings which waste their time and mental effort.

Best,
Radon