core import first > then contrib

So to summarize, the problem is that improper contrib translations could mess up your existing translations. This is easily fixed by not using the overwrite method for imports, but opting for the 'keep' method. As far as I see, there should be no general problem by using that method, so I modified the code to use 'keep'.

We don't know what is a core module, unless we add a definitive list of core modules into autolocale. Modules can be placed anywhere, intermixed with core modules.

No, core translations are not in one file. Core translations can be in any number of files. You'd better read the reasons behind autolocale development the first place: http://drupal.hu/english/node/7 Look, a core translation could easily be 30-40 files. This functionality will be built into Drupal 6 core as it seems now, so we need to think in "core level solutions" as far as autolocale advancement goes.

How would you distinguish the core modules from the contrib modules in this case? Sure, we tell people not to unzip modules into the modules folder, but use the sites/all/modules or sites/$sitename/modules folders, but noone can stop people from putting modules directly into the modules folder.

Well, autolocale imports component (module, theme) PO files in the order of appearance in the system table (in the order of a SELECT SQL query returning them). MySQL at least returns the rows in insert order, so core modules inserted before contrib modules will have their translations imported first. We cannot do anything about core translations imported later then contrib modules (ie. core modules enabled a few days or weeks later), but at that time, you already should be familiar with translations in your database, so you would get surprised if a core translation modifies existing strings.

That said, using 'keep' is also better to keep user modified translations, altered using the web interface (which we also could not distinguish from imported translations). My 'overwrite' default behavior was a deliberate attempt to push a solely PO file based translation approach, but that does not fit Drupal core either, so it was time to modify it to 'keep'.

The localization server in development (which will provide a web interface for translations) will enforce translation sharing between core and contrib, so contrib translations will not be able to mess up your existing strings at all, even when imported with overwrite mode.