In our number format syntax [1], it is possible to define a locale used for the number formatting: [$-lcid] or [$xxx-lcid]; and the lcid is defined as a hexadecimal number defined in [MS-LCID]. Microsoft has deprecated the use of LCIDs (as described in the Overview section of [MS-LCID]); and "locale names" are encouraged instead. LCIDs are not guaranteed to be available for any given locale. The use of "locale names" (i.e., BCP-47 language tags) is also much more user-friendly and intuitive: e.g., when asked today for a way to force "[NatNum12]0" to "language Marathi ( mr-IN )", I would be glad to be able to respond like "use [NatNum12][$-mr-IN]0"; but instead, I needed to lookup the LCID, and the result would be "[NatNum12][$-44e]0". Let us support this [$-BCP-47] (and [$xxx-BCP-47]) syntax, in addition to the one using LCIDs. This wouldn't introduce a potential for backward incompatibility, because currently, such syntax would produce an error (e.g., "=TEXT(123; "[$-en-US]0")" gives Err:502, and trying to define it as a cell's number format is rejected). Potentially, this new format could become the preferred one, keeping the LCIDs for backward compatibility only. Additionally, only format strings saved verbatim (e.g., in TEXT spreadsheet function argument, or in Basic's Format function argument, or passed to XNumberFormats::queryKey) would be incompatible when used in older versions, because e.g. in cell/field format strings, they would become cell locale instead, saved compatibly. [1] https://help.libreoffice.org/latest/en-US/text/shared/01/05020301.html [MS-LCID] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-lcid/a9eac961-e77d-41a6-90a5-ce1a8b0cdb9c
Since lcids are hex numbers, any BCP-47 tag consisting of [a-f] country code only would conflict. Then maybe the syntax could be like [$--BCP-47] or the like.
I don't see that Excel would support some [$-bcp47] modifier. So if at all then another modifier should be used that could be omitted from the format code, like [bcp47:...] or [lt:...] Anyhow, the correct way to have "[NatNum12]0" for Marathi is to select Marathi from the language list and enter "[NatNum12]0" as format code. Doing so the user doesn't have to know neither LCID nor the language tag. (and an input of "[NatNum12][$-44e]0" is converted to anyway). For the TEXT() function, the literal format code from an interoperability and i18n pov is a complete horror already anyway, this would add just more mess. Furthermore, users might come up with syntactically valid language tags but for which no locale support exists. These could only be rejected. If a valid and supported [lt:...] was given, that would have to be converted to the matching [$-...] LCID anyway to make things work. So, I'm not very convinced..
Let's abandon it then :-D
The idea itself is good though if we could support arbitrary locales and ignored the mess of TEXT().