(Much of this page is copied directly from Markus' collation v2 page as much of the same applies to number formatting.)
The "number format v2" reimplementation is currently in progress as of 4 May 2015 and is being done based on many of the elements of the design doc below. (See also the !!number format v2 log!!)
(First ideas noted early 2014)
What if we could implement Decimal Format anew?
What if we could write new NumberFormat API from scratch?
The current code ("v1") is large and complex, and feels fragile. Fixing bugs and adding new features has become nearly impossible to do. The number formatting code is very tightly coupled, so changing one area of code is likely to affect everything else.
The current DecimalFormat API is a classic example of "kitchen sink" API. It supports ~ 36 named attributes all of which can be set independently of each other as well as any number of unnamed, mutable attributes. No one quite understands how all these attributes interact. DecimalFormat objects are big and can format and parse any amount under the sun including currency amounts. Users often want to just format small ints.
The CurrencyPluralInfo sub API of DecimalFormat is broken. It allows the user to specify a different format pattern for each of the 6 plural forms. The flaw in this design is that the plural form is determined by both the amount and the format pattern, not just the amount.
Several different object types each with only one primary purpose. Avoid object types that do a little bit of everything. Easier to test: More isolated functional units with their own tests.
Write a data-driven test so that new test cases are easy to set up and understand. Also ICU4C DecimalFormat, ICU4J DecimalFormat, JDK DecimalFormat, and new DecimalFormat can all be run against the same data driven tests.
See here for Data Driven test syntax along with instructions for running and maintaining data driven tests for Numberformat.