Eemeli Aro

> However, I can't figure out what is the expected difference between `FluentNumberOptions.maximum_significant_digits` and `FluentNumberOptions.maximum_fraction_digits`; and between `FluentNumberOptions.minimum_fraction_digits` and `FluentNumberOptions.minimum_significant_digits`. I'll consider those redundant, and I won't implement any specific...

To me this looks like it should be an ICU extension, something like `{$n :number icu:offset=2}`.

You know, we could also consider separating out options that really are adding to the function's nominal input operand to _also_ be operands. As in, allow for function expressions with...

Based on a first look and consideration, this formulation of the selection algorithm should give the same results as the current one, but with a few caveats (in no particular...

We do already now include this: https://github.com/unicode-org/message-format-wg/blob/22707c778374ad4e2c9116efc805cedc295ef985/spec/formatting.md?plain=1#L474-L475

The earlier issue should perhaps be closed; this is a better formulation.

Thank you, it's better! Still a couple of things: - The `selector-list` values need to be _resolved values_, as they need access to the _formatting context_. - It would be...

Another thought: The only thing that's done with the result of **selector.compare(key1, key2)** is to check if it's **better** or not. So the **worse** and **same** values to be collapsed...

Yes, the best-match algorithm continues to be complicated, and its expression ought to be iterated on.

In our current logic, earlier selectors/keys are considered to always have higher priority than later ones, so by that definition `x * *` is considered a better match than `*...