I think the issue is that the filing is about reverting the promotion to
default gems, which is different to the use case of making it (or what a
ruby user wants to use) more flexible.
The ideal scenario would be to have a fully customizable ruby, at all
times. Something like, if we compare MRI ruby and mruby, and be able
to include any gems as-is no matter which "base ruby" is used, like
LEGO building blocks. Like in the old discussion for making stdlib
gemified.
[...] Nevertheless it does not address the "disk consumption"
concern. I also previously forgot to mention possible increased
network bandwidth required to build and distribute the cloud image.
See - you may have valid reasons, and I agree on the part that ruby
should ideally be as customizable as possible at all times. But others
have valid reasons too, and in this context I agree with the promotion
to a default gem. Granted I am biased because I like the did-you-mean
gem, but I also don't think that the reasoning should be to NOT
promote it because of your use case being more important than other
use cases, such as being able to use the did-you-mean gem by default.
It's a bit similar to warnings or not showing warnings - they can be
annoying, but they can also be helpful, so you have a situation that
is somewhat orthogonal. The proper long term solution would be to
allow for the desired flexibility.
MRI ruby targets "regular" ruby users and their use cases may show
a range of different "wants and needs". Note that I do not necessarily
have an opposite opinion to your issue request; I just don't think that
should be the primary line of reasoning. The ideal solution would be
to see that gem/bundler would allow for as much "customizability" as
possible.