malte,
keys should be keys not one of the localizations. one good reason is what lars says, you can change one localization without having to change all localizations. we have to stick with that. another reason is that one of the goals of globalization is to allow people to write packages in their native locale. there is no need to force everyone to write a package in english and then localize it to japanese. your method would force them to do that and that breaks the first principle of globalization: "do not assume ANYTHING about the locale of an application," not even what language the code is written in.
i am still not totally familiar with the current plans for localization but i was assuming that the multiple adp's concept was already established. it was defined by henry (or jeff) in his original globalization proposal at arsdgita and was also used in the globalization of acs 4.6 (acs java). i think the request processor is already set up for this although we'd have to ask rob mayoff. the idea is that one you have negotiated the locale and character set for a request you can then find the adp that best matches the request. locale and character set negotiation is well described in my globalization docs that are linked from the presentation.
having different layout based on locale is essential, and that is the main point of having different adp's for each locale that requires different layout, not for each that requires a different language. the language is taken care of by the trn tag. the layout by the adp file. as an example, it allows you to have address forms that match each locale. that way not everyone gets the "zip + 4" widget when they are asked to enter an address, just those in the states.
finally can you explain why changing the separator from _ to something else would help with the above. the _ is the standard separator used by everyone and i would hate to change convention unnecessarily.
yon
