Let me answer this one by one:

1. "The semantics must be precisely defined":

If this happens in PEP634 I don't think it was intentional, and I'm pretty sure the authors would be happy to complete any incompleteness that it has. I would happily have a more accurate description (I drafted a non-official one for a much earlier version of PEP-622, https://github.com/dmoisset/notebook/blob/master/python/pep622/semantic-specs.md ). Can you clarify where you see these imprecisions?

2. "It must be implemented efficiently":

I don't think "efficient implementation" was a priority in PEP634, although I saw your proposal defines this as "same performance as the equivalent if statement", and I'm quite sure that level of performance can be achieved (if it isn't already by Brandt's implementation). Finding the best way to optimise wasn't a priority, but I think if there was anything in our implementation that would make optimisations harder we would consider them as a change. Do you think anything like that has been presented?

3. "Failed matches must not pollute the enclosing namespace": 

This for me is one of the less-desirable parts of the proposal, and was agreed more as a matter of practicality and an engineering tradeoff. If you have a reasonable way of solving this (like putting matched variables in the stack and popping it later) reasonably I'd be much happier putting that in.

4. "Objects should be able determine which patterns they match."

This is something that you and I, and most of the authors of 622 agree on. What we found out when discussing this is that we didn't have clear what and how to open that customization. Some customization options added a lot of complexity at the cost of performance, some others were very simple but it wasn't clear that they would be actually useful, or extensible in the future. This has a lot to do with this being a somewhat new paradigm in Python, and our lack of knowledge on what the user community may do with it beyond what we imagined. So the decision was "pattern matching as it is presented without extensibility is useful, let's get this in, and once we see how it is used in the wild we'll understand better what kind of extensibility is valuable". For a crude analogy, imagine trying to get the descriptor protocol right when the basic python object model was being implemented. These things happened as different times as the use of the language evolved, and my opinion is that customization of the match protocol must follow a similar path.

 

5. "It should be able to handle erroneous patterns, beyond just syntax errors."

I'll be answering this based on the example in your document, matching RemoteCount(success=True, count=count) where RemoteCount is a namedtuple. The code is likely an error, and I'm in general all for reporting errors early, but the kind of error detection proposed here is the kind of errors that python normally ignore. I find that example really similar to the kind of error you could make writing "if remcount.count == 3: ..." or going beyond this example "maxelems = configfile.read(); if len(elems) == maxelems: ...". There are many type errors that python ignores (especially related to equality), and Python has already made the decision of allowing mixed type equality comparisons everywhere, so why do you think pattern matching should be different with respect to this? In my opinion trying to "fix" this (or even agreeing if this is a bug or not) is a much more general issue unrelated to pattern matching. Given the current status-quo I normally trust python type checkers to help me with these errors, and I'd expect them to do the same with the "erroneous" match statement.
If there are other examples you had in mind when you wrote this I'd also be happy to discuss those.

I'll try to get some time to review your specific counterproposal later, thanks for it.

Best,

    Daniel