Re: when do we remove backward compatibility definitions?

[Paul Eggert]

On 11/21/2017 12:03 PM, Eli Zaretskii wrote:
> Let's instead solve practical problems with such issues.  Are there
> any practical problems here?  If so, what are they?

The practical problem is that when we have cruft in the Emacs source 
code that makes maintenance harder, we sometimes would like to remove 
the cruft to simplify maintenance, so long as removing the cruft doesn't 
unduly affect users (we warned them long ago that the feature was 
obsolete, etc.).

In cases like this it's helpful to have a guideline for when we can 
simplify the code by removing obsolete cruft. For platform issues (old 
POSIX platforms that don't support newer POSIX features, for example), 
the general rule of thumb I use in Emacs and elsewhere is, "If the 
platform's supplier no longer supports the platform, then Emacs doesn't 
need to worry about supporting it either."

My attempt at writing a guideline for supporting obsolete Emacs features 
is intended to be along similar lines. It is not meant to be 
prescriptive and so I shouldn't have used the word "policy" to describe 
it. It is merely meant as a common-sense guideline for when Emacs 
features are so obsolete that they can be removed if that simplifies 
maintenance.