Number.Amount + Decimal.Amount

A potential direction the proposal could take is to introduce a Number.Amount type.

The semantics of Number.Amount would be:

1. Cheap, lossless conversion of numeric portion to and from Number
2. The range and maximum precision represented by Number.Amount would be limited by the range and maximum precision represented by Number (hopefully this is obvious)
3. Unit conversions take place on Numbers and have Number-like behavior
4. The precision field could take a number of different shapes, to be discussed in a separate issue

Meanwhile, the Decimal proposal would gain a Decimal.Amount type that largely parallels Number.Amount, because we don't want Decimal to have capabilities that Number does not have.

The primary advantage of this direction is that it avoids blessing string decimals as a first-class numeric data type (something the Amount champions insist is not the intent, but which has a risk of being interpreted that way by the community). It also means that unit conversion is easy and cheap to implement, since it would be defined to work in Number space.

With this direction, we would not have a BigInt.Amount, because the use cases are not evident.

CC @o- @eemeli @jessealama

Read the Number and Decimal proposals alongside this issue, focusing on the proposed Number.Amount and Decimal.Amount semantics, unit conversion behavior, and the unresolved precision field. Done means reaching a decision on this proposal direction, including whether BigInt.Amount is excluded; no implementation files or tests are identified here.