The constructor-like syntax for class patterns is the part I like least about this proposal. It seems to expect that there is a one-to-one correspondence between constructor arguments and instance attributes. While that might be common, especially for DataClass-like types, it's certainly not always the case. Some attributes might be computed from multiple arguments (or looked up elsewhere), and some arguments may never be saved in their original form. I fear it will be extremely confusing if an attribute being matched by a class pattern doesn't correspond at all to an argument in a valid constructor call. For example, this class would make things very confusing:

You could match an instance of the class with `case Foo(c=x)` and it would work, but that might come as a surprise to anyone familiar with the class constructor's argument names.

Even when attributes and constructor arguments do line up, the class pattern syntax also seems a bit awkward when you are not required to match against all of the non-optional constructor arguments. I imagine `case datetime.datetime(year=2020):` would be a valid (and even useful!) class pattern, but you can't construct a datetime instance in that way since the class has three required arguments.

To sum up, I feel like using constructor and keyword-argument syntax to access attributes is an abuse of notation. I'd much prefer a new syntax for matching classes and their attributes that was not so likely to be confusing due to imperfect parallels with class construction.