Let me split my case into two points:

1) The intuition that the right-hand side of `a | b` is a fallback value
2) The claim that `a |= b` is a common idiom to assign defaults

About 2)

It appears that the idiom in 2) is less common than I assumed. My expectations
were shaped by working with a C++ codebase where the `|=` operator was sometimes
overloaded in such a way (since there is no `||=` operator in this language).
Unfortunately, I have not found similar uses of `|=` elsewhere (e.g. in Boost).

To illustrate this with a specific case nonetheless, that C++ codebase had a
generic data type modelled after Haskell's Maybe. In Haskell, `Maybe a` is a
type which can be empty (`Nothing`) or hold a value (`Just a`). In the C++
implementation, the operation `a |= b` would assign `just(b)` iff `a` was not
empty.

About 1)

I still believe that there is an intuition that the right operand of `|` is a
fallback value, and this intuition may lead people to wrong use of dict unions.

To make this intuition more explicit: Consider other operations that behave like
OR in a Boolean algebra, such as logical OR, and set union. Conceptually, these
operations perform one or multiple checks on the left operand, and only consider
the right operand if the check "failed".

- With logical OR, short-circuit semantics are widespread (cf. C, UNIX shell, or
  Python itself). The right operand is only evaluated if the left operand
  evaluates to false in a Boolean context.

- With set union, implementations typically start by copying the left operand,
  and add entries from the right operand if they are not already present in the
  copy. This is also what CPython does in `set_union` (via `set_add_entry`).


As another case in point, overriding items from the right operand is already
provided by `dict.update`. A `|=` operator which provides for the complementary
operation of filling in missing items would have made for a more orthogonal set
of operations. When formulated in terms of `|`, the two operations only differ
in the order of operands.

> Here's our current proposal for docs. Is there anything you'd like to add?
> https://github.com/python/cpython/pull/18659/files

I find this quite clear. It already points out the behaviour in question.


To conclude, different semantics for dict union would have been preferable in my
view, but I guess that ship has sailed. Other than changing dict union semantics
I don't think there is anything actionable left here. Maybe my input still has
some value in clarifying expectations some users may have for this new feature.

Thank you for your openness about this late input to the discussion.