Essentially just a base-10 version of floating point. It will work better for accountants and others performing conventional math done with base 10, but no fundamental advantage. The problem stems from trying to represent an uncountably infinite set with a finite set -- at the end of the day you end of with a very sparse approximation.
Dismissing it as "better for accountants" feels trivializes the problem.
There's billions of lines of code in circulation dealing with fixed-decimal currency formats.
The choices have always been:
* Scale things up and down (do your math in cents and convert back to dollars at the last minute), which is an easy opportunity for off-by-2-orders-of-magnitude bugs
* Use floating points and pray nobody notices the all but guaranteed errors
* Use something like BCD and have to explain it to everyone
* Deal with some custom format or language-specific type, kissing portability goodbye, and depending on implementation, possibly poor performance
A well-established decimal-friendly type, whether this, decimal128, or something else, provides a go-to solution to a very common problem.
BCD has been around since the earliest CPU's. I get the importance of using base 10 for finances, but there is nothing new offered here that I can see.
