Currently, the selection of locales for the monetary locale is based on the l10n directory's contents (much like the UI language choices). This is bad and the cause of quite a lot of issues/misunderstandings, as we fall back to system-provided monetary locales, not define our own ones.
We should base the drop-down on the list of locales actually supported in the system; this way we'll know that the setlocale() calls with actually work and provide the right monetary results.
This approach should be checked for all setlocale() calls in CiviCRM; i.e., whether we actually try to set a given locale that we know the system should support, or are we trying to set it blindly, based on l10n contents.
(Alternatively, we can provide monetary locales - decimal delimiter and thousands separator - for the languages that we offer and skip setlocale() calls altogether.)