I've added a comment to issue #271 (comment) where I try to show that the first match is really not possible to implement properly.

Because the programmers / translators / tooling might not have enough information to make those decisions about sorting.

The EM proposal contains a section on best matching algorithm s:
"Annex 2: Multi-selector matching algorithm alternatives"

And the code here implements a selection using something similar to the score proposal here.

A few differences from my thinking and this proposal (to consider, none of the blockers from my side):

1. Nitpicking: a score between 0 and 100 or similar, using integers (always easier and safer than fractional values)

2. The * is 0, and not under the control of the function. The function is not even called, * matches everything.
   I think that allowing functions to "mock" with the value of * is confusing, open for abuse. There might be some pros, but I don't see any.

3. The score for no match is negative. If a function returns a negative score for one item in the tuple, the tuple does not match. We can drop the iteration on the tuple items and go to the next tuple.

4. The score for the whole tuple is the sum of all the item scores, SQUARED
   This matches the intuitive idea of distance in the real world.
   The distance from origin to a point:

• in 1D space is x (same as √(x²))
• in 2D is √(x² + y²)
• in 3D is √(x² + y² + z²)
• in n dimensions is √(d₁² + d₂² + ... + dₙ²)
  There is no need to extract the root, as we compare the scores.

The pseudocode is something like this:

bestMatch = null
bestMatchScore = -1
for each tuple // iterate vertically, to select the best matching `when` entry.
    for each key in the keys of the current tuple // iterate horizontally
        tupleScore = 0
        if key == '*'
            itemScore = 0
        else
            itemScore = function.invoke( value_to_select_on, key ) // -1 or 0-100
        if itemScore < 0
            tupleScore = -1
            break from the inner cycle (on items)
        tupleScore += itemScore * itemScore // item score squared
    if tupleScore > bestMatchScore
        bestMatchScore = tupleScore
        bestMatch = tuple
if bestMatchScore == -1 // we didn't find any match, not even `* * *` (which would be zero)
    error, ultimate fallback option is missing
return bestMatch

We can even optimize a bit.
If the tupleScore is the max possible value (100*100 * number of items), we can return, as we found the best possible match (all items have a score of 100)

a score between 0 and 100 or similar, using integers (always easier and safer than fractional values)

I agree. This is an illustration.

The * is 0, and not under the control of the function. The function is not even called, * matches everything.
I think that allowing functions to "mock" with the value of * is confusing, open for abuse. There might be some pros, but I don't see any.

* is never zero, but you can't think of "matching vs. non-matching". For best match, there are cases where * matches better for a given selector. I illustrate this with * == other:

The key thing here is that that we need to decide between best and first match. If we choose best match, we can then describe best match using one of the mechanisms such as you describe.