What limits should Amount mathematical values have?

Amounts are intended to be containers for mathematical values, possibly labelled with a unit. As of writing, there are no limits on the range of these values. We expect that, in a very large portion of uses, programmers will probably stay within the range of Number (or, looking ahead, to Decimal, which is based on IEEE 754 Decimal128, in which values take up 128 bits).

Do we want any limits to be imposed? What should they be?

Considerations for limits in the spec:

• Although BigInt can be thought of as being an unlimited range, implementations may have limits for them (e.g., hundreds of thousands of digits might be support, but millions of digits wouldn't be).
• Intl.NumberFormat has various limits on the number of digits it can handle.
• Clarity and consistency across implementations.

Considerations in favor of no limits in the spec:

• Amount does not support arithmetic; an Amount is a data holder for a mathematical value. The only calculation that needs to be done on their underlying mathematical values is rounding, which is done (at least, as of writing) only in the constructor and the .with methods when a fractionDigits or significantDigits option is passed in that is requires the mathematical value to be approximated.
• Implementations are permitted to enforce limits as they see fit, analogous to what they do for BigInt.

Start by reviewing the issue's alternatives for limiting Amount values, including Number, Decimal128, BigInt, and Intl.NumberFormat constraints. Compare consistency across implementations with the case for implementation-defined limits; done means reaching and recording a clear specification decision.