You're using markdown in the descriptions (in an XML registry)?

Start with the default. Describe each separately. Also, your phrasing suggests binary matching, but, in fact, our selectors rank and filter options. You don't mention the * handling.

The choice of markdown is intentional, because:

1. It's remarkably human-readable even in syntax form.
2. It's a relatively well-defined formatting language that doesn't require any <> that would conflict with the surrounding XML.
3. It's rather well supported as a syntax for code comments.
4. What's the alternative here?

I merged the suggestion here, but kept the thread open to account for the markdown discussion. Also: not mentioning e.g. "match quality" was intentional, as this selector only has two quality levels: exact and category, with the former always pre-empting the latter.

The * is not mentioned here because it is not a concern for a selector function; its behaviour is defined directly in the selection algorithm, and the selector is never consulted about it.

I have no objection to markdown. I just didn't want to let it pass by unremarked?

The * is not mentioned here because it is not a concern for a selector function; its behaviour is defined directly in the selection algorithm, and the selector is never consulted about it.

I'm not sure that's correct. In the case of plural I would be unsurprised to see the keyword other in CLDR be treated as a synonym for * in MF2 (to prevent having two defaults). If that's not the case, some mention of the relationship is probably called for??

other is not special in the syntax the way * is. In Pattern Selection, it gets special treatment in:

• Resolve Preferences 2.ii.b. (this is where it's left out of the keys sent to the selector)
• Filter Variants 2.i.b.
• Sort Variants 5.iii.c.

To make it possible to use e.g. only one and other as English plural variant keys, leaving out the * variant, we would need to:

1. Remove the syntax validity requirement to always have all-* variant.
2. Refactor the Missing Fallback Variant error into a formatting error for when we fail to select any variant.
3. Add a way for the registry <match> element to state that its values attribute exhaustively covers the input space, so that a build-time validator could still verify that the variant set is complete even if it does not include a * variant.

I would enthusiastically support such a set of changes.

I'm not talking about leaving out * but about documenting that * and other are equivalent. What we don't want are tools expanding a variant set from 0/one/* to 0/one/other/*. I wouldn't make the latter set invalid (other is just a string) but it is pointless to write.

I think defining that here would require us to define the behaviour of e.g. selection on {horse :plural}. Would that silently match an other variant, or would it emit an error and end up selecting the * variant? And in e.g. Polish, could that match a many variant?

Do we really need to define in the spec such internal behaviour of a selector in error cases?

The documentation of ICU's PluralFormat says:

You always have to define a message text for the default plural case "other" which is contained in every rule set. If you do not specify a message text for a particular plural case, the message text of the plural case "other" gets assigned to this plural case.

This is equivalent functionally to *. Do you disagree that tools should be told about this equivalence? Do you think we should promote developers having to write 0/one/other/* messages? Note that the error being handled here isn't "horse" but rather "missing translation" in which the runtime locale would prefer to match few but the message doesn't provide few (usually because the message hasn't been localized and we're getting e.g. the root locale message).

This says nothing about error handling. Note that we do specify that horse is an error by making :plural and :number's operand anyNumber, but that's wholly separate from describing what the plural cases are.

Do you disagree that tools should be told about this equivalence?

No, I agree that we should communicate clearly how * works, and that it's very similar to other in MF1. But I don't think this is the right place for that, because the rules about * apply to all selectors, not just :number.

Do you think we should promote developers having to write 0/one/other/* messages?

No, that's unlikely to be helpful in most cases. But we should let them know that it's at least possible, for the rarer cases when distinguishing other from * is important.

This says nothing about error handling. Note that we do specify that horse is an error by making :plural and :number's operand anyNumber, but that's wholly separate from describing what the plural cases are.

This sounds like a detail we ought to talk about some more, later. My position here would be that we can define in the spec a minimum of what must work, but that we should not seek to define behaviour for all possible inputs. Also, we ought to have normative text separately from what's in the <description> saying what a :number ought to be doing.