> Given the semantics of {}.update({}) and { * {}, * * {}}, it is clear what is the preferred behavior,*

Sorry, I honestly don't understand what's the meaning of that (I know a little bit of Python, C/C++, ASP.Net, etc...).

Concerning adding dicts: thinking over it I am more or less neutral as I think that somebody that would dare doing it would feel the pressure of reading the docs to know what the operator would do (e.g. merge distinct keys & overwrite-left/concatenate/ignore-right values of duplicate keys?).

On the other hand in Python I keep trying from time to time to e.g. cast "integer"s into "bytes" using "bytes(my_integer)", which results in a "my_integer"-bytes variable initialized to zeroes (ha-ha), so whatever would be implemented to add dicts using an op might be good for a large part of users but at the same time bad for the other part (that are inexperienced, have a different ways of thinking, etc...) => this might in turn weaken the language's acceptance.

They're the standard forms of doing dict merge in python, and generally the first answer whenever someone asks (both overwrite with right dict key/value on collision, concatenate keys otherwise).

{ * * d1, * * d2} -- unpack the two dicts and feed them both as input to dict comprehension to construct a new dict.

d1.update(d2) does the same merge strategy, but modifying d1 in-place.

Sure, there's five different ways to go about handling collisions, but there's already a well-defined, commonly used methodology, so it's fair to implement syntax sugar for it. It's also not too difficult to understand, and easy to look up (particularly compared to {* * d1,* * d2}).

And I'm not actually aware of any other merge strategy being included in the python stdlib, which implies that this strategy being the best useful default, has been decided long before this operator came into question.