Wait... why are we doing this? What is wrong with letting the "implementation-defined method" decide that the * key is the best match?

What you're requiring here is that the selector method return "no match" in order to reach * and that the higher-level caller of the "implementation-defined method" then choose the fallback vs. allowing the selector method to make that determination. We haven't discussed this previously, so I don't understand why we are changing this text.

I don't think this is intended as a change to the selection method, but a clarification of what's already in the Resolve Preferences section below.

If you think that should be changed, that might be best discussed in a separate issue or PR.

@aphillips Yes, as Eemeli said, it's meant to be a clarification of what's already there. The existing definitions of "Resolve Preferences", "Filter Variants", and "Sort Variants" only pass literals to "the implementation-defined method". So the method can do whatever it wants if it's passed anything that's not a literal, such as *. Saying "The list of keys passed to this implementation-defined method does not include the catch-all key *" is another way of saying that these definitions don't rely on undefined behavior.

We're being overly normative. In fact, the "implementation-defined method" is probably overly normative. I don't particularly like, on re-reading, the text on lines 27-29 (since my old implementation considered the selector to be a function doing the comparison and this is different from a method that "compares each to the selector")

I also don't think that the "when one selector" followed by the "when more than one selector" structure is that helpful. I would probably write this section as:

When a message contains a match statement, it determines which expression matches by ordering the available keys.
In a message with more than one selector, the number of keys in each variant must equal the number of selectors.
Each key corresponds to the selectors in the match statement by position.
To determine the match, each selector is used in turn to order and filter the list of keys.
In order to select the single best variant for a given set of inputs, the full list of variants is filtered and sorted. Each variant with a key that does not match its selector is omitted from the list of variants. The remaining variants are sorted by key preference, with earlier selectors in the list of selectors having a higher priority than later ones.
The highest-sorted variant is selected.

Notice that my text is equivalent to the text here, but doesn't say how a selector is implemented or how sorting is implemented. It just says what must happen when processing a message.

@aphillips Would you prefer the current proposed change to be included or dropped from this PR? Getting this merged would make it easier for you to file a subsequent PR with your proposed rewrite.

On the one hand, I would prefer not to merge non-consensus text wherever possible. But I agree that the lack of other reviewers leaves little evidence about whether this should or should not go.

Let's merge this. I will file my comments as a separate issue and create a PR with them once this is merged. Sound like a plan?

Good typo fix.

I find this example nearly impossible to read?

I don't agree with the idea of an "English-language formatting context". It should be in terms of a locale.

I'll come back an suggest an edit when I have a few more minutes.

The edit could maybe be a separate PR?

Yes.

Actually, on second thought... it's a typo correct. Fix the typo. We'll address the text separately.