I believe hsbt may be able to answer your question. reline is probably the future anyway.
https://github.com/ruby/readline has not received an update in ~2 years, for instance.
I do, however had, disagree conceptually that:
require 'readline'
would/should require reline, though. Users who do say may 100% want to get readline, so a
forceful redirection towards reline may NOT be what ALL users want to have or see if they
use require 'readline'. I still have some legacy code that uses readline; while I am fine
to transition towards reline (and I still think reline could need better documentation),
I do not think it is a good idea to force another library into the way how users use
something or specify loading of library xyz, to then suddenly get library abc when they
clearly did not specify this.
It's not up to the ruby core team, IMO, to force deprecations onto users like this, e. g.
to force them towards reline even if they specified "require 'readline'" specifically. That
just would not seem right to me.
Let people decide on their own if they want to switch towards reline; readline-ruby
is only available externally, anyway - see:
https://github.com/ruby/readline
(I understand that this is not 100% what hsbt wrote, but it is my opinion that when
people do require 'xyz' that ruby should try to load xyz, rather than abc because
some random developer tries to force people to use that suddenly. Since ruby core
already uses reline, that should it be, and then the proper way to get it used is
via require 'reline', rather than require 'readline'.)
I am not entirely sure a deprecation notice is necessary either. IMO it would be
better to recommend reline officially and let people transition towards it at their
own pace. ruby-core can use reline as it is just fine, without any problem.
In regards to removal: I actually thought readline was already removed and put onto
github, but I understand that part of your question; in this case I would think it
is best to remove readline from ruby core, and let the readline-ext be available as
gem people can install as-is. We have had a similar situation with psych and syck
(for yaml) and that was fine. I used syck for a few years after psych became default,
and then one day I was just using psych and stopped using syck altogether. I do not
remember any deprecation warnings were necessary there.
Updated by 
Updated by 
Updated by 
Updated by