What is your evaluation of the proposal?
+1
My remaining concerns are mainly around anonymous vs named opaque types and the interaction with where clauses and constraints (i.e. Protocol<.AssocType == T> shorthand for combined protocol and associated type constraints without naming the constrained type). I understand the desire for shorthands, but personally would prefer always having named opaque types, so that where clauses et al would be natural and just would follow the already existing syntax. But more importantly, even the initial limited implementation in SE-0244 should try best to avoid getting into syntactical deadlock when the implementation is later extended. For example the idea in the proposal about extensions to typealiases as a way to solve conditional constraints feels like natural solution.
some -keyword feels appropriate for this feature. Also, no underscores please.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes. It's needed for Collection in standard library and @nuclearace also pointed out the need for it in 3rd party frameworks.
Does this proposal fit well with the feel and direction of Swift?
Yes, as long as the details in the syntax fit well into Swift.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Have been following and participating to discussion since Opaque result types - #350 by Ben_Cohen, have read the proposal, tried out the experimental toolchain.