Right, that the behavior is changing and that this could break existing code. It might have been an interesting idea at the time group_by was introduced, but I doubt that Matz will feel the change is compelling enough to break compatibility today.

In other words, it might be desirable to return an empty array for a group key that is part of the collection that we group over (classes in the example), but it'd be better to cause an error for group keys that are outside of the collection (i.e., not classes in the example).

That would mean that the default proc should (for this example) be something like
{|hash, key| hash[key] = [] if key.class==Class }
Of course, that cannot be part of Ruby, unless maybe as a third argument of some form to group_by.

In other words, it might be desirable to return an empty array for a group key that is part of the collection that we group over (classes in the example), but it'd be better to cause an error for group keys that are outside of the collection (i.e., not classes in the example).

That would mean that the default proc should (for this example) be something like
{|hash, key| hash[key] = [] if key.class==Class }
Of course, that cannot be part of Ruby, unless maybe as a third argument of some form to group_by.

I certainly didn't intend for the default value to have some idea of the type of comparison done by the call to group_by, that seems to go well outside the scope of group_by and just general ruby semantics. It seems counter intuitive to me that while the point of the method is to return a hash of arrays, the return value would produce either an array with some values in it or nil. It returning a hash that produced arrays with some values in them or an empty arrays means you're only dealing with one type of thing, an array.