I think the issue isn't the base, but that Javascript stores all numbers as 64-bit floats.

The decimal proposal is a vague enough that it is unclear if it would improve on that; if it was arbitrary-precision decimals, that would be an improvement. If it is limited precision but better than Number (seems unlikely), it would be an improvement. If it is limited precision but not better range/precision than Number, just decimal rather than binary floating point, its probably not an improvement. The proposal is vague enough that any of those would fit.

JS has BigInt now. You can kinda fake BigDecimal with it, but none of the built-in operators will work.

How do you fake BigDecimal with BigInt? My immediate intuition would have a 3-tuple (a, b, c) which would construct the decimal with a representing the numbers before the decimal separator, b the number of zeroes immediately after the decimal separator, and c the numbers after the zeroes. e.g. 1.000054 would be represented as `[1n, 4n, 54n]` and 3.14159 as `[3n, 0n, 14159n]`.

Is there a better way?

What about a 2-tuple with two numbers, one being the BigInt and one being the exponent. So 1.000054 would be (1000054, -6) = 1000054*10^(-6).

Yours is probably more space efficient though.

This is basically floating-point.

IEEE 754, BTW, allows for 10-based floats, but IDK if anybody uses it.

Yours is more space-efficient for real-world numbers.