+1.  IMO, the implementation of methods as semantically abstract as "collections" should drive the decision of where they reside.  #size and #do: are the core methods of Collection.  Any operation that can rely solely on those should reside in Collection.

When useful abstract operations are needlessly stuck in subclasses like SequenceableCollection, that, itself, becomes a question of semantics.  And of design and usability, too.  Especially when one discovers they have a use for it in a non-Sequenceable, "Why," becomes the always- distracting first question.  Often, people will simply re-implement something else rather than take a detour to lobby to move it up or modify the core library, thus continuing to reinforce a false notion of, "See?  It's not needed except for Sequenceables.."

I lost a similar argument several years ago with #joinSeparatedBy:.  I was generating and processing hundreds of thousands of query objects, each having a collection of named arguments (key / value pairs), whose names (keys) simply had to be unique.  And because it absolutely did not matter what order the arguments were printed on the output stream, a Dictionary was the obvious choice for that collection.  Nevertheless, the naysayers argued that their own personal lack of context to such a use-case meant, "random result order makes such a feature questionable".

It is, until it isn't.  The only reason #do: on Dictionary makes sense (e.g., "should it enumerate the 'values', or the 'associations'?) is due to our own experience as Smalltalkers of using it.  Every operation on Dictionary's has non-obvious semantics to anyone not familiar with Smalltalk.  This is why the implementation should weigh most heavily in such decisions, with semantics and personal experiences being secondary weights.

Best,

  Chris