@wzup we intentionally only support currencyDisplay: 'symbol' due to the amount of data that needs to be fetched (locale data) to support "name" and "code", it is a compromise. On top of that, we are only picking up the symbols that are different from the currency identifier, you can see what we fetch here: https://github.com/andyearnshaw/Intl.js/blob/master/locale-data/json/en.json#L2176-L2197

This is a reduce process from here: https://github.com/unicode-cldr/cldr-numbers-full/blob/master/main/en/currencies.json#L752-L758

We don't have a plan to solve this in the interim I'm afraid, because it will increase the size of the data required by the polyfill to function, but if someone wants to write a PR that enables to use of those extra entries as part of a custom build, I will be happy to take it. In other words, the default build should still add support for basic functionality, and a custom build can extend the size of the data.

+1 on this as I've been running into this recently as well for ja-JP locale currency formatting. Is there a compromise solution that we can use to only support the "name" field for the main currency or two that the locale supports? e.g. Only supporting JPY for ja-JP and USD for en-US.

wouldn't it be possible to provide add-on packages that work together with this main package to fill in the names and even historic currencies no longer in circulation like "DDM" (see https://www.currency-iso.org/dam/downloads/lists/list_three.xml)?

An add-on package intl-currency would bring in new currency formats for locales. Its single export could be fed to Intl using Intl.__addLocaleData(locale) which it would simply merge with the existing locales.