Daniel-
If there is a problem with naming conflicts, then that is a very good reason to have separate wikis.
The distinction between "separate wikis" and "one wiki" is a lot blurrier than you describe it. Having proper multilanguage support within a single installation would lead to a setup very similar to our current one from the user POV, but with a lot of advantages which come with having a single database (e.g. it becomes very easy to have combined RC, watchlists, single sign-on etc.).
That problem does not really exist for meta, wikisource, and wikibooks.
Naming conflicts are largely independent of the purpose of the wiki; the larger a wiki gets the more likely they will become. Right now you could have a "Merchandising (German)" and a "Merchandising (English)" page, for example, but that is really just a workaround for a proper design and it's going to bite us in the ass sooner or later (e.g. template names are usually short and likely to cause conflicts).
The current MediaWiki design - separate installation for each language - was flawed from the start. It has served us reasonably well, but if we redesign it, we should do it properly.
In short, I think we should only divide things up if there is a compelling reason. Meta in *particular* is there for multiproject and multilingual coordination. How is that coordination going to happen on separate wikis?
The only compelling reason for having separate wiki installations is that it is the only way for the current setup to achieve - see only the language you care about - different language user interfaces (including MediaWiki: namespace) - standard interlanguage links - no naming conflicts
These things would be important on Meta as well to encourage international cooperation and reduce English dominance, hence my support for subdomains. With a properly designed system, we don't need to use separate installs for Meta, Wikipedia or any other wiki - they are all going to behave the same; you only see the languages you care about. (Emphasis on plural here.)
So, for example, when you would go to www.wikimedia.org, it would take the preferred language from your browser and show you, e.g., www.wikimedia.org/de/, but prominently show the other languages as well. You could set the order in your user prefs if you want. If you create a regular link from under de/, it would point to a German page. If you create a link from under en/, it would point to an English page. In your recent changes view, you would see only the RC for the languages which you have set in your browser or MediaWiki prefs.
The only thing that would change about the effective user experience on Meta is that it would become a lot more convenient, and that you could easily move only in your local language if you want (this is already possible in a half-assed way through the localized Main Pages). The balkanization you speak of does not exist here. And if you're afraid of too much language separation, there's no reason not to allow languages to be used liberally, e.g. on discussion pages, even in the subspace which is technically French, German or English.
Now, with a separate install, you lose certain functionality, which I agree is important, such as having multiple languages in one RC view, and having a single login. As Angela pointed out, the current interlanguage link system is also needlessly redundant. I can agree that this creates more trouble in the short term than it is worth, and that it leads to a certain amount of balkanization, although I think that this is being exaggerated for dramatic effect.
But then, if you agree that doing a proper multilingual setup for all wikis is a good and necessary thing, we should set a sizable bounty on it ASAP and do it the right way rather than have ever larger inconsistencies. This can be combined with single sign-on at least on a project level, something which a lot of people have been waiting for. I would be willing to write up a bounty proposal which specifies the necessary functionality if there is general agreement that this is what we should do.
Regards,
Erik