ちょっと前までの規格では単一式(≒セミコロンとセミコロンの間)の中の評価順は基本的にコンパイラが好き勝手に弄る事が許されてた
例えばa[++b]=cとかはヒトの常識的にはbをインクリメントしてからa[b+1]にcを代入するけど、別にa[b+1]にcを代入してからbを増やしたって構わない(この前のどっかでa[b+1]を参照してればその方が最適化したら効率的かもしれない)
そんな感じで最適化に都合がいいように評価順には寛容すぎるほど寛容だったんだが、カオスを防ぐためのルールがあって、それが「単一式で同じオブジェクトを2回変更したら未定義」というもの
例えば(a+=1)+=1はどっちの1を先にaに足してもいいが、そういう自由度がある時点で未定義というルールになっていた
もっと分かりやすい例だと(a+=2)*=3は最初のaが1なら常識的には9になると思うけど、評価順ルール的には3を先に掛けてから2を足して5にしたっていい
9か5の二択で済むこれはマシな方で、ポインタが絡むと収拾がつかなくなるから、同じもん2回以上書き換えたらもう知らん未定義じゃってのがCとちょい前までのc++の規格の趣旨だった

で、この話をさっきのiostreamに持ち込むと、operator <<はconstメンバー関数じゃないので、cout << foo << barはcout << fooと、(cout<<fooの戻り値==coutの参照) << barの2回のcoutへの変更を順序は不確定な単一式でやってることになる。つまりさっきのaと同じように未定義動作って事
(cout <<fooを先に実行しないと戻り値確定しないからこっちが先に決まってるのでは？と思うだろうけど、規格の文言上はcout <<fooの戻り値を「予測」して<<barの適用を先にやったって構わないのである。そんな病的なコンパイラがたまたま実在しなかったから今まで問題にならなかったんだろうけどね)

という話がrangesのパイプでoperator|のチェーンの検討をしてるときに発覚してみんな真っ青になって慌てて評価順のルールが見直されたっていう、まあアホ臭い話でした
幸い病的な最適化コンパイラが生まれる前だったから規格文言だけの話で実害はない