An alternative is to support a new REAL_DOUBLE data field type, once #3046 is implemented (i.e. once we know we can use it in PHP code). This solves the problem of inflated currencies, and reduces the chance of accuracy errors - but it is not as clean.
Or, to use BIGINT, once #3046 is implemented and deal in cents. Probably not very future proof and somewhat messy.

For reference, I looked into it and MySQL 32 bit can handle BIGINT (64 bit), DOUBLE (64 bit), and very long DECIMAL up to 65 digits. This is because it uses either advanced CPU instructions or compiler magic to work beyond the system architecture's word size.