I took a cursory glance (it's EOD Friday here so I'll have to look again next week) and in general this seems like an improvement, and in the couple of places where code owners might prefer the legacy style I suspect you could make 1-off adjustments.

That being said, I'm having a hard time understanding the state of the proposal; the original design has a combination of positive and negative comments, and the only other (public?) comment I see from @goderbauer implies not a strong amount of support.

If there were other outcomes or conversations you can share to explain this change, that would be great.

Sure! I'd be happy to give an overview of what I've learned.

Hixie engaged with the doc the most, and also was the most strongly opposed to pattern-matching out of the people who responded.

His negative responses (e.g. here, here, here, and here) are summarized really well by a comment he made at the top: simplicity is more important than concision.

There were other spots where he gave a more neutral response (here, here, here, and here) along the lines of "neither one is very readable."

As far as his supportive feedback, one comment in particular stuck out:

i think non-pattern switch is probably simpler than a long if chain, because the reader can immediately see "ok we're going to just be comparing this one value against a bunch of other values" whereas with the if chain you have to check "is every condition the same form? are they actually chained with 'else' properly?" etc. When we start adding patterns to the switch though I think it can quickly get more complicated.

That said, I think there are cases where even pattern switch is better than an if chain. For example if you have a sealed class hierarchy and you're checking against every option and matching every field, that's probably clearer than a bunch of ifs and casts.

Mylo Fawcett also engaged quite a bit and showed more support overall for implementing patterns.
But one notable exception that I found surprising was the firm disapproval of doing an Offset object pattern assignment.

I was also interested to hear from Bob Nystrom that Dart pattern-matching has a lot in common with Swift syntax.

It's definitely not cut-and-dry whether pattern-matching is overall "better" or "worse" than the alternative (there are some situations where whether the pattern is more readable depends on how long the variable names are). There's a lot of variety, both with regards to how patterns would apply to a particular code snippet, and also pertaining to the individual reactions and overall opinions that different people have.

That being said, there was one huge takeaway that hadn't occurred to me until I started talking with people and gathering feedback: map patterns are far more readable than object patterns.

if (someMap case {'key': final Object value}) {
  // ...
}

It's distinct, concise, and expressive: the key being directly adjacent to the value is huge.

By comparison, object patterns are often not as great, especially with the leading colon:

• Multiple people have mentioned that Size(:final double height) looks wonky.
• And Size(height: final double height) is more verbose and not much less confusing.

To decide what went into this PR, I basically just included all the map patterns, and then some other things that I thought looked nice.

in the couple of places where code owners might prefer the legacy style I suspect you could make 1-off adjustments.

Sounds like a great plan!