>I wonder why =+ is so obviously a mistake

Consider

  x = -5

now how about:

  x =- 5

One makes x negative 5, the other subtracts 5 from it. And under this design of the operator the only difference is a space.

It's the same with +, just that we're not used to seeing unary plus in the wild.

>> x =- 5

I think you mean: x -= 5, which indeed is different.

I'm showing how it would be under the original operator design which was reverted, which was "=-".

I think because it's ambiguous with unary plus (a = +b), since C isn't supposed to have significant whitespace in most circumstances.

You also run into problems with a=*p and a=-b, which are perhaps more likely.

But they could've fixed that by going a=(*p) and a=(-b);

Kind of how we use (*p)->next instead of *p->next where p is node_t**

That seems a little backwards and barbaric, though right?

Imagine if we had to watch out for this as a common pitfall:

    // BUG! Actually subtracts x from current val of neg_x.
    neg_x = -x;

Even moreso, how would these two lines behave? Would they differ in semantics?

    n = -5
    n =- 5

Overall, -= is just so much less ambiguous.

EDIT: To your point about ->, I personally think C would be better if:

    *p->next

parsed as:

    (*p)->next

instead of:

    *(p->next)

but maybe now I'm not thinking through all the parsing impliciations :)

I've found struct fields that are pointers far more common than pointers to pointers to structs, so if nothing else it feels like *(p->target) is a more widely useful interpretation of *p->target than (*p)->target would be.

Regarding "n = -5", it would presumably be interpreted as "n=(-5)", same as today. Operators don't have spaces in them. So "n- -5" is "n-(-5)", rather than "n--5" (not valid).

As you note in your edit; we already have to watch for that pitfall :)

so really the best way out is to be as verbose as possible imo; a = a + c or auto nodep = *nodepp; nodep->next;

Compilers and compute performance have grown to make the difference negligible for code output and compilation times but they definitely take a lot of mental complexity out of such scenarios (anything helps when grokking 10k+ lines of code).

But originally there wasn't a += or =+ lexical token! Those things were scanned as separate tokens, and could be written = +.

So that is problematic; If {a}{=}{-}{b} means a = a - b, then you have no way to write a = -b without parentheses like a = (-b).