How to handle old drush aliases in dr

Problem/Motivation

Old aliases in the list of commands under dr list transfered from Drush may use deprecated wording such pm:enable, even though there is a concentrated effort to phase them out in the Drupal user interface, code comments, etc., since #3162049: [meta] Better wording of the module life-cycle admin pages.

How should we handle deprecated aliases?
E.g. we don't list them in the UI, they work or not, you get a helpful message that they're going to go away, etc?

Update aliases to match command?
We could also update some aliases, to match the current command, E.g:

Currently: drush role:perm:add (rap,role-add-perm)
Proposal: dr role:perm:add [rpa]

Steps to reproduce

Proposed resolution

1. Handle old aliases: Different scenarios

   • Remove old aliases
     A fresh start where we let users adapt to the change.
     PRO: Will result in a cleaner interface, where the help text is not pushed down to the next line. It will faster phase out examples of people leaving "... just drush en pathauto" comments, since these aliases for deprecated commands such as pm:enable will be forgotten over time.
     CON: Can seem a bit harsh, Drupal users accustomed to using old aliases will need to adapt to the change.

   • Remove old aliases, inform the user
     Remove the aliases, but show a helpful text, from a dead aliases graveyard, e.g. drush en pathauto returns Did you mean "drush in pathauto"?
     PRO: Same as above. Helps experienced Drupal users to adapt to the change.
     CON: Can seem a little harsh, but informs the user about an alternative.

   • Keep old aliases, hide in UI, warn the user
     We keep deprecated aliases, but hide them in the UI. We continue to support calling them, which triggers a deprecation message - similar to the 'graveyard' scenario but with a bit of re-animation involved, e.g. drush pm:enable pathauto returns something like Warning: pm:enable will be deprecated, use ex:install or exin.
     PRO: Same as above, but nudges experienced Drupal users to adapt to the change. We could decide to completely remove support in a future release.
     CON: None.

   • Keep old aliases
     We keep the old aliases.
     PRO: Drupal users accustomed to using old aliases can still use pm:enable, and don't need to adapt their methods.
     CON: Results in a cluttered user interface, where the help text is pushed down to the next line. Will keep bad practices such as people leaving "... just drush en pathauto" comments, which can confuse new users, since alias and command don't match.

2. New aliases: Candidates for an update

   These are the Drush commands with more than a single alias, the first section are those that most need a look over. We could hide the old dashed aliases, and update to use a new alias that matches the actual order of elements. First is the original drush, and then dr suggestion.

   drush pm:install (in,install,en,pm-enable,pm:enable)
   dr ex:install  [exin]
   
   drush pm:uninstall (un,pmu)
   dr ex:uninstall  [exun]
   
   drush role:perm:add (rap,role-add-perm)
   dr role:perm:add [rpa]
   
   drush role:perm:remove (rmp,role-remove-perm)
   dr role:perm:remove [rpr]
   
   drush user:role:add (urol,user-add-role)
   dr user:role:add [ura]
   
   drush user:role:remove (urrol,user-remove-role)
   dr user:role:remove [urr]
   
   drush watchdog:delete (wd-del,wd-delete,wd)
   dr watchdog:delete [wd]
   
   drush watchdog:show (wd-show,ws)
   dr watchdog:show [ws]
   
   drush watchdog:tail (wd-tail,wt)
   dr watchdog:watchdog:tail [wt]
   

   Commands with multiple aliases

   Do any of these drush commands need to be updated? Feel free to move up, under "New aliases: Candidates ...", with a suggested new dr alias :)

   runserver (rs,serve)
   cache:rebuild (cr,rebuild)
   core:edit (conf,config)
   core:requirements (status-report,rq)
   core:status (status,st)
   php:cli (php,core:cli,core-cli)
   php:eval (eval,ev)
   site:install (si,sin)
   

Remaining tasks

1. Decide whether to keep, warn about, or remove the old aliases.
2. Decide which new aliases to update, to match the current command

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet