Currently the locale of a person has a foreign key constraint to the users table. Sadly this does not make much sense, as you could create persons who are not users of the system (e.g. with the contacts system), but who should have a locale variable stored, so you know which language to use when communicating with them (especially when you are using I18N for this).
What is being proposed ?
Change the foreign key constraint from users to persons for the users_preferences table
Why is it good?
It will allow other applications to store the person preferences in one central location and if the person becomes a user afterwards, the upgrade is easy.
Why is it bad?
user_preferences table would reference persons, not users, therefore the name could be misleading. Changing all calls in the toolkit from user_preferences to person_preferences might be a hell of an upgrade script (especially if you have foreign key constraints).
Alternative:
Change acs-lang to not use user_preferences for storing the locale of the user but create a new table too hold the locale and the party_id. This would allow us to assign a locale to a group, e.g. in .LRN where the group locale for the community could override the user locale to have a french class' interface appear in French. It is just considerably more work which might not be necessary.