The discussion at https://discuss.rubyonrails.org/t/new-2-7-3-0-keyword-argument-pain-point/74980/2
is already quite long, and I do not intend to add to the discussion there, largely because I think
it may be difficult for matz and the core team to follow everything easily (it's quite a long
thread already).
Some folks gave specific feedback, and suggestion; there was one particular proposal to delay
ruby 3.0. I would rather like to NOT see ruby 3.0 release delayed and I think most of us want
a xmas ruby release. We are like little kids, well, many of us. ;)
More specifically, to the keywords situation: I am not really affected directly, because I don't
really use ruby keywords nor do I need them (I tend to stick to the matz ruby oldschool style
so perhaps I am just getting old finally, but I like oldschool ruby :D).
I have, however had, noticed that there are LOTS of warnings generated by other programs.
A new rails create command triggers a lot of warnings too. And I think, while warnings are
not necessarily harmful per se, they can be quite annoying and verbose. I believe that this
is actually a real problem in the sense that ruby users may, at the least right now, get
a "too chatty" ruby. I am not saying that other issues don't exist, since evidently it
takes others time to re-write code etc..., which I am aware of is never a lot of fun. But
I am mostly just explaining my own particular case - I am not really affected directly,
but indirectly (with the messages) - not a real pain point for me at all, but a bit
spammy and noisy.
Matz gave specific suggestions, options, asked for opinions too.
I have no particular strong opinion either way; I do agree that in the long run it is
better to have a keyword argument situation in ruby that is simple to understand and
simple to use, so it should be changed. But perhaps it should not be changed for
ruby 3.0 (and then there may always be people who want a change, but when everyone
has a different opinion, you can't really make everyone equally happy at the same
time).
So I am mostly neutral, with perhaps a tiny bit in favour of considering to delay
the changes to post ruby 3.0 release.
I think that independent of this, it may be a good idea to consider how to change
ruby if change means that it may require ruby users to adjust their code (e. g.
incompatible changes). Perhaps some release process that covers a range of ruby
releases, like:
3.0 to 3.2:
1 - 2 big changes
3.2 to 3.4:
1 - 2 big changes
And so forth. That is just an example, to try to find some way to make the change
sets smaller or something like that.
By the way, I think one or two among the ruby core team, also maintain some gem
with backwards-compatible code, e. g. where new features can be used in older
rubies. Perhaps we could think about something like this for "future" ruby too,
a bit similar to the frozen string literal change (but I am not necessarily
saying we should use lots of magic syntax in # comments; I mean this more
in general).
Updated by 
Updated by