There's an interaction between {minimum,maximum}FractionDigits and roundingIncrement that I think this is failing to account for by setting defaultRoundingIncrement in ignorance of the former:

const input = 55.555;
for (const maximumFractionDigits of [0, 1, 2]) {
  for (const roundingIncrement of [1, 50]) {
    const nfOptions = {
      style: "currency",
      currency: "USD",
      maximumFractionDigits,
      roundingIncrement,
    };
    let pattern = String(10 ** -maximumFractionDigits).replace(/[0-9]/g, "#");
    const output = new Intl.NumberFormat("en", nfOptions).format(input);
    console.log(`${input} as ${pattern} @ increment ${roundingIncrement}: ${output}`);
  }
}
/* =>
55.555 as # @ increment 1: $56
55.555 as # @ increment 50: $50
55.555 as #.# @ increment 1: $55.6
55.555 as #.# @ increment 50: $55.0
55.555 as #.## @ increment 1: $55.56
55.555 as #.## @ increment 50: $55.50
*/

Given the above, what would we expect from currencyPrecision: "cash", maximumFractionDigits: 0 vs. currencyPrecision: "cash", maximumFractionDigits: 1 vs. currencyPrecision: "cash", maximumFractionDigits: 2?

Speaking personally, I would expect currencyPrecision to always apply at the same absolute position regardless of output precision, which suggests to me that the algorithm needs to account for digits options (and for that matter, notation as well—we arguably have a preexisting bug where currency-derived fractional digit count defaults are applied even when the decimal point is moved away from its absolute position, as in new Intl.NumberFormat("en", { style: "currency", currency, currencyDisplay: "code", notation: "engineering" }).format(12345).replace(/^.*\s/, "") resulting in "12E3" for JPY but "12.35E3" for USD).

Put another way, I think I expect currency-derived precision and corresponding rounding to apply only when notation is "standard" (i.e., not even when the decimal point happens to be in the right place with scientific/engineering/compact notation), and only in that context does it make sense for a new option to further refine the output.

Oh that's a good point. Great catch. I should have noticed that.

oh, very good catch!

A couple of thoughts:

1. It seems reasonable to throw if currencyPrecision: "cash" is set and notation isn't "standard", since cash rounding only really makes sense in standard notation.
2. If cash rounding only makes sense if notation is "standard", this suggests that the non-cash option for currencyPrecision should be something other than "financial" — maybe just "standard"?

It's an issue not only when notation isn't "standard" but also when a different value was set for minimumFractionDigits or maximumFractionDigits. So the condition when this is used should be exactly the condition when _cDigits_ is used.

I'm kind-of okay with any of the following outcomes:

1. Do a complicated check that the setting isn't present with conflicting options
2. Ignore the setting if conflicting options are present (this is how we behave when e.g. currencySign is present but style is not currency)
3. Define the algorithm similar to how you have it defined here and let people shoot themselves in the foot

gut feelings when I see those potential outcomes worded that way:

3 seems bad (needlessly confusing for users)
1 seems less bad but not in keeping with the rest of the spec
2 seems least bad

on edit: Making sure I understand 2: if minimumFractionDigits or maximumFractionDigits is set, currencyPrecision is ignored, correct?

Concretely the change would be the following in SetNumberFormatDigitOptions:

Undo your change on this line:

        1. Let _roundingIncrement_ be ? GetNumberOption(_options_, *"roundingIncrement"*, 1, 5000, 1).

And add the following line:

             1. Set _intlObj_.[[MinimumFractionDigits]] to _mnfdDefault_.
             1. Set _intlObj_.[[MaximumFractionDigits]] to _mxfdDefault_.
+            1. Set _intlObj_.[[RoundingIncrement]] to _defaultRoundingIncrement_.

I think that gets the job done?

Observation: not sure how the spec scopes variables but this Let is not in the same lexical scope as the code below that reads from it. If it is a problem, you could Let it be 1 further up and then Set it to something else when needed.

This is fine; aliases are implicitly scoped to the containing algorithm: https://tc39.es/ecma262/multipage/notational-conventions.html#sec-algorithm-conventions (emphasis mine)

Once declared, an alias may be referenced in any subsequent steps and must not be referenced from steps prior to the alias's declaration.

Just a reminder to bikeshed all parts of this: the option name and both string options.

I'm wondering about the difference between "financial" here vs. "accounting" for currencySign (i.e., should both options instead use the same "accounting" value?).

My sense is no, since there's situations where you'd want to use one and not the other. I can easily imagine someone using (for example) a personal finance application wanting debts represented by wrapping them in parentheses, but also not caring about anything smaller than a cent.

Avoiding confusion between the options is one reason why I think "financial" would be a better name than "accounting" for this option.

I'm comfortable with generalizing beyond ISO 4217, but this seems like the kind of data for which an implementation could conceivably have reasons to diverge from CLDR (i.e., superior local knowledge). So I'd rather have the reference be a recommendation rather than a requirement (aligning with other sections of the spec).