I somewhat agree with the explanation, so I think the suggestion in itself is fine
as such.
I believe there may be a language design consideration, though, e. g. whether matz
thinks that this makes sense from a language-design point of view (see the other
explanation about the various attr* methods and why there is no attr* variant
that e. g. combines reader methods with a trailing '?' character).
Another smaller issue, if it is an issue, may be for ruby newcomers. For example,
say that a new user comes to ruby and asks about nil.to_a and nil.to_h
specifically - will there be an explanation somewhere? I am really just thinking
about the new-ruby-user situation in this regard, e. g. they may like to
understand why .to_a and .to_h may be special but not other .to* (if there
are any ... I don't even know how many exist for nil).
Note that these two points are not meaning that I am against the suggestion
at all - it is only meant to "carve out more details" from the proposal if
possible. :)
In my own code I usually check first for nil, before doing any further
checks, even "boolean checks" (if a variable is true or false). Not sure
if that is the best practice, different people write code differently,
but I sort of adopted that a long time ago. So I may not be the ideal
target audience either as I currently don't quite seem to do much on
nil, except actually I do indeed sometimes do .to_s, to ensure that
I have a string. This can indeed be a bit complicated sometimes, if
we have to distinguish between nil, string and a symbol. But I still
agree with your basic statement - it somewhat makes sense to me since
nil.to_a and nil.to_h will always "reproduce" the same result just
as .to_s would (and should, since it is nil).