>> Well, that fix does not break any tests.  Anything asking for
>> #contents that only needs #upToEnd deserves to break.
>
> Etoys loading and saving may be relying on the (inconsistent) bahavior, though.

It looks like there are only 36 senders of #contents in the Etoys
package.  So it shouldn't be too tough to patch Etoys.

Etoys is a very important application.  At the same time, every other
stream-type behaves one way w.r.t. #contents.  Should we tolerate this
inconsistency in the general-purpose library to accomodate one
application or should the application be changed?

Is Etoys running on the trunk image?

> And there is #with:
>
> (RWBinaryOrTextStream with: 'abc') contents => 'abc'.
> (MultiByteBinaryOrTextStream with: 'hello') reset contents => 'abc'.

As well as:

  priorPosition := myMultiByteBinaryOrTextStream position.
  myContents := (MultiByteBinaryOrTextStream with: 'hello') upToEnd.
  myMultiByteBinaryOrTextStream position: priorPosition

I only used #on: for the example.  I think #contents should
consistently answer the full contents, regardless of which stream-type
or how it is created.