Dan,

> THEREFORE I would propose simply to forbid all bit manipulation on negative
> numbers

It's a well-known fact the there are two flavours of right shift,
arithmetic and logical [1].  The one that we call #bitShit: seems to be
logical, whereas many people are expecting it to act arithmetically.
Your comment about #bitAnd: is entirely relevant -- and reinforces the
position that bitwise operations are logical (and not arithmetic) in
Squeak.

What's needed is a second bit shifting primitive, #bitShiftArithmetic:
(which could even be implemented [by a suitably apathetic implementor,
on a particularly busy day] as:

    Integer>>bitShiftArithmetic: distance
        ^distance < 0
            ifTrue:  [self // (1 bitShift: distance negated)]
            ifFalse: [self * (1 bitShift: distance)]

;-) ;-).

Since any Integer receiver of a message in Squeak has a well-defined
sign and representational size, implementing a more serious version of
#bitShiftArithmetic: is no problem -- the sign can always be preserved.

FWIW, I also posit that *logical* shift (#bitShift:) for a negative
receiver and a negative non-zero argument should return a positive
result.  (But I wrote far too much machine code in my youth -- I'll don
the asbestos suit and await the flames... ;)

Regards,

Ian

[1] Except, of course, on the PowerPC -- where there are several
    million distinct kinds of shift and rotate, lurking inside the
    "rlwinm" family of instructions.  PPC = RISC?  Pull the other one! ;)