Instead of perpetuating the idea that the number of locales is a precious resource tied to directory entries, the routines could parse the user supplied string instead of working with a table of all possible permutations of ll_CC.CTYPE. This means simplification for the build system, simplification for those reasoning about what the structure representing a locale should look like, and it also adds features without calling for a cliche, tower of babel discussion.
Every field enclosed in brackets denotes the parameter(s) to the LC_ function on the LHS: LC_COLLATE=[ll]_CC.[CTYPE] LC_CTYPE=ll_CC.[CTYPE] LC_MONETARY=ll_[CC].CTYPE LC_NUMERIC=ll_[CC].CTYPE LC_TIME=ll_[CC].CTYPE LC_MESSAGES=[ll]_[CC].CTYPE That means that they can be indices to separate flat tables. N.B. POSIX says that locales don't need to map to directories, so why try to fit this into an expanded hierarchical structure when it's clearly not made for it?
