Hi Nicolas, I understand the angle you are seeing this from, but these
we distill these points down, we end up with no real-world value; but
some unintended negatives, in fact..

> did you see the implementation of Collection>>size?
>
> size
>     "Answer how many elements the receiver contains."
>
>     | tally |
>     tally := 0.
>     self do: [:each | tally := tally + 1].
>     ^ tally
>
> Let's forget a minute about specific subclasses.
> Does iterating over the whole collection is really the best idea for
> implementing isEmpty?

Asking this question is already assuming too much.
Collection>>#isEmpty should not be optimized in terms of another
method two sends away.  Collection is the ivory tower which only
codifies the elegant definitions of the general behaviors.  We should
let the subclasses be concerned with the nitty-gritty implementation
details needed to go crazy with their (less elegant) optimizations.
**We shouldn't try to make performance optimizations in Collection.

> When we implement a message in Collection, we should think in term of
> Collection, not Interval, Set nor Array.

The old implementation already was implemented in terms of Collection.

> We're talking of several things here:
> - universality of the default implementation:

The old implementation was universal.  #size always has and always
will be part of Collection.

>   we don't need to know about the size to tell if empty

Not any more than we need to avoid it.  Not any more than we need to
initiate a #do: enumeration (which is very expensive for some).

>    not all collection have a known size

So what will happen if they're sent #size then?

If #shouldNotImplement then they will override #isEmpty.

> - optimization:
>   old implementation is fast for collections having an optimized size,
> catastrophic for others.

Those are more rare, they should override #isEmpty for their specific needs.

>   new implementation is reasonably fast, and full optimization can be
> restored with a few 1-liner.

"Reasonably fast" for which subclass?  We can't ignore the subclasses.

> - cleverness:
>   IMO this is not more clever than, and quite logically connected to
> implementation of size
>
> I agree that having several implementations for the sake of optimization is
> not ideal.

It told me something was amiss with this change.  Too many subclasses disagree.

> That's what would have curbed my enthusiasm.
> Though I doubt about any noticeable slowdown in anything else than
> micro-benchmarks.

The SQLCollection example would be a large degradation.
-----
It all distills down to slightly-negative.  We should revert it.