Thanks for the detailed feedback! I'd like to address your general comments regarding the motivation section here directly instead of splitting it up for each comment.

While I was preparing to write this PEP, I reread a lot of the discussions from the last few years. One of the most common arguments against these operators was that they are basically just syntactic sugar and don't add anything new. Technically speaking this is correct. We both know that these would still be great additions and make certain coding patterns a lot easier to write. However, the question I asked myself was how can I best explain why all the other patterns are only suboptimal.

I ended up with the structure you read. It starts at "beginner" level with simple truthiness checks. I've actually seen code like this in production. Sometimes lazy code is enough even if it contains problems. It continues with the explicit is not None checks, before ultimately adding the assignment expressions as well. try and match were added as these were the other often suggested builtin alternatives.

By showcasing how each of these work, I can point out the subtle issues each option has and provide a justification why ?. and ?[ ] should be added.

In the end I also wanted to avoid falling into the same, IMO trap, PEP 505 did with just showing nice examples and basically saying the new operators are just better. https://peps.python.org/pep-0505/#examples That's also why I deliberately moved the common patterns towards the end of the motivation section.

--
I admit the example isn't ideal. It's adopted from a discussion post I saw. However, I wanted to add some "real" class and variable names for these examples. Of course, a?.b.c?[d].e would work as well, but that oftentimes seems contrived and far away. PEP 505 did that and I always found that somewhat unintuitive, even though it's strait forward. https://peps.python.org/pep-0505/#the-maybe-dot-and-maybe-subscript-operators

I'm happy to change it if we can come up with a better example.