I'm at best -0 on this, and on the edge of -1.  We already supply mutate-in-place operations for when this is wanted, and, e.g., for lists, it's as dead easy to spell as

    L1 += L2

Half the point of the hack for string catenation was that the similar-looking

    S1 += S2

did _not_ mutate in place.  But that spelling for lists already does.

Beyond that, is it actually safe for set operations?  Those need to compare elements, so can call into Python code via custom __eq__ implementations, which in turn can do anything, including boosting the number of ways to reach the original inputs (i.e., increase their refcounts).  For that reason I believe it can be visible if, e.g.,

    Set1 = Set1 & Set2

mutates the original set bound to Set1.  The binding via name `Set1` may be the only way to reach the original set before that statement executes, but the process of computing the RHS _may_ create additional references to the original set object.

Even if it doesn't, when element __eq__s are running other threads may run too, and pick up ever-changing values for the set object `Set1` refers to if it's mutated in place.

None of those were potential issues for hacking string catenation (which never calls back into Python code - and holds the GIL - for the duration).