RE: Delete variables obsolete since Emacs 23

[Drew Adams]

> >> The phrase "may be removed" seems a bit vague.  Would "will be removed"
> >> or "will probably be removed" be more accurate?
> >
> > No, it won't.  Primarily because we don't really know whether we will
> > remove it, let alone when.  It depends on too many factors that we
> > cannot predict.
> >
> 
> In that case, would a two-step process not be better?  First declaring the
> function "obsolete", and when it is known that it will be removed declare
> it "pending-removal" with a target major version.

In my experience, organizations typically avoid a
lot of commitments to future changes.  Instead, it's
about _no longer_ committing to something that's
currently committed to.  It's about removal of
commitments, not imposition of new commitments.

(Sometimes there's informal/unofficial mention to
some users that it's likely XYZ will be removed
at a specific point.  But even that is generally
avoided.)

Typically there are two possible stages:

1. Deprecation (sometimes calling the thing "obsolete").
   The thing _remains supported_.  There's no longer a
   _commitment_ to active development - that's all.

   Users are told that the thing _might_ be desupported
   at some time in the future.

   Because of the removal of a _commitment_ to actively
   develop AND the removal of a _commitment_ that the
   thing will remain forever, users are advised to
   start moving away from using the thing.

2. Desupport.  This is _optional_.  A deprecated thing
   need never be desupported.  And typically there is
   some (sometimes announced, sometimes not) minimal
   time period or number of intermediate releases,
   needed between deprecation and desupport.

   Something that's desupported gets no support.
   Trying to use it typically results in a no-op or
   raising an error.
___

That's my experience.  YMMV.  And of course nothing
requires GNU Emacs to follow any particular outside
convention or typical behavior.