Hm, for some reason I was thinking that this was safe to do after the feature freeze. Let's get to it then!

Batuhan, perhaps we should change the linked issue for your AST validator PR to this one. That way we can close the old catch-all PEP 634 implementation issue and keep the discussion focused here.

Nick, you might find the discussion on this mypy PR (https://github.com/python/mypy/pull/10191) helpful. In particular, Adrian raises some points about ways we could make type inference in the AST a bit neater. For example: not all patterns can be used for mapping keys. Perhaps there is a way to organize parts of the AST hierarchy that makes this a bit more concrete (though we should be careful to not limit reasonable syntax extensions in the future by doing so).

A few notes, just from skimming the outline here:

> MatchValue(expr value)

MatchValue technically contains an expression node, although the actual expressions it can contain are quite limited (dotted names and negative/complex numbers, if I understand correctly). Can we gain anything by splitting this up into nodes for each of these (MatchValue(identifier* parts), etc...) instead?

> MatchClass(expr cls, pattern* patterns, identifier* extra_attrs, pattern* extra_patterns)

If I remember correctly (this part was implemented a while ago), collecting the different positional and keyword arguments in the parser is sort of simple since we can pass around sequences of keyword nodes easily. I *think* that the new proposed design would require hacks like creating dummy MatchClass nodes with *only* the keyword parts and later combining them with the positional arguments and a class name, since it keeps the keyword names separate from their arguments. Maybe some of the parser folks on this thread can chime in on that.

Also, continuing the theme above, I think we can be more specific with "expr cls" here (maybe "identifier* cls"). 

> MatchRestOfSequence(identifier? target)

In the interest of brevity, maybe "MatchStar" or something?

> A NULL entry in the MatchMapping key list handles capturing extra mapping keys

I think we could just give MatchMapping a "identifier? rest" member, right? That way it becomes a bit easier to use, and we don't need to worry if it's last or not. It also keeps us from having to handle empty entries in the keys.

Oh, also, the ast unparser will need to be updated as well.