So, in effect, what you suggest are two changes:
a) Support for special message keys that are made up like ${package_key}.${locale}_${message_key_desc}. I don't think this is a good idea. I would say though that it might make sense to drop the 5 letter ISO code dependence and allow two letter ISO codes as well, but *only* if it refers to the first part or if we can enforce case sensitivity when comparing it with the users locale. Though, to be honest, I fear supporting this will have a performance impact (as you need to check if the string for the locale exists, if the string exists for the partial locale, if the string exists for the default locale for the user locale and if the string exists for the default locale of the system).
b) Dropping the constraint on the en_US message (well, I think it says system locale) existing before. I do agree that this is desireable and should not have too much of an impact. Though changing this will require a thorough rewrite of quite some pages and procedures in acs-lang. If you would implement this, write a TIP and you can count on my support (unless I missed something).
As for a different suggestion, well, you could register these additional locales using the TCL code and a callback on acs-lang (enable language), where you set the en_US message to the same value (e.g. lang::message::register_with_default, that will try see if the message_key exists in the default locale and if not register it in the default locale along with your own locale). This will prevent the large cluttering of en_US with unneeded language keys.
