It is clear that increasing the ease of installation of thirth party modules makes a clear view on translation locations impossible.
May be we should rethink one and other to recreate some transparency for both human and machine where translations can be found/installed/created. Here's my rethinking attempt:
There are core language files and thirth party module language files
There are distributed language files and locally created language files
and the combination: distributed thirth party module language files and locally created thirth party module files
What never should happen, is that locally created language files are overwritten by an upgrade.
What always should happen is that locally created language files have priority over distributed files.
Therefore I suggest to search for langstrings in
I suggest to write all translations by default in
Translators who maintain a language pack can switch to the moodledata/lang/XX_utf8 folder
Translators who want to share their translations for thirth party modules can find their work in the local_XX folder and send it to the maintainer of the module, who can put it in the right place for redistribution (like it should be done already).
I don't like the idea of saving localised lang files together with the thirth party module files: I don't like to make it necessary to give apache write access to a /public_html folder, especially since it is not necessary (we have the moodledata/lang folder). It also makes upgrades more difficult, since you cannot replace the whole Mooldescript (you have to search your modifications on language files first in a bunch of different /mod folders)
The only modification to the interface requires for this, is that it defaults to local_utf8 for translations and that it doesn't offer the opportunity to put non-standard module translations in /XX_utf8.