I now understand the += proposal.
Let me see if I can respond to some of my own points.

(1) += HAS to be a binary selector rather than a compound from a
    binary selector and an assignment symbol because it IS a
    binary selector.

(2) There is a marked syntactic difference from other binary
    selectors, however.  The thing on its left must be a simple variable.

(3) The effect of var $= exp, for some selection of $ binary selectors,
    is
	var := var perform: #$= with: exp
    although presumably it would be implemented using a direct message
    send rather than really using #perform:with:

(4) The complaints by several people that writing x := x + y just isn't
    a big deal miss the point.  The point is to have notational
    uniformity between updating an object (which is the value of x)
    that can increment itself and updating a variable (whose value
    is immutable and cannot increment itself).

(5) There could very well be an automatic relationship between $= and $.
    Add to object a bunch of methods like
	$= anObject
	    "Implement the $= for immutable receivers.
	     Mutable receivers should override this with something better."
	    ^self $ anObject
    (Here as elsewhere, replace $ by +, -, *, /, and so on.)

This proposal doesn't solve any problem that I have.
However, it does create some problems.

(a) If I *should* happen to create a -= method for some class
    (such as Polynomial, maybe) it will no longer be legal for me
    to write (srs at: 1) -= monomial.

    It will need an exceptionally well worded error message to explain
    why what seems like (and according to all current textbooks, IS) an
    ordinary binary selector "misbehaves".

(b) If I *think* x and y hold oops to mutable things like Points,
    but I'm wrong, then x += y will not only appear to succeed,
    it will change the value of x, which may come as a nasty surprise.

(c) There are a whole bunch of update assignments one would like to have
    such as raisedTo:=, min:=, max:=, for which the efficiency and
    uniformity arguments are equally compelling, but which *cannot* be
    handled this way.  For somewhat different reasons, while vectorwise
    logical operations make sense, |= is unavailable.

If this were Perl, I'd say "fine, go ahead, one more wart on the
gargoyle."  This is Smalltalk.  I think the idea creates more problems
and inconsistencies than it removes.  The e-correspondence so far has
shown that it's quite good at confusing people.

Nothing actually stops anyone writing
    x := x += y
right now, and nothing (Smalltalk, got to love it) stops anyone
adding += and friends to Number.  So most of the apparent benefits
can be obtained with no compiler changes.

Now can I have {v1. v2. v3} := expr  back?  (:-) (:-)