So, what should we have built in into the core? And this is what I'd call 'basic i18n and multilingual support'. Ideally, the core alone should be able to deal with a single language -whatever language it is- without more modules enabled. And then we can have some core modules when more than one language is needed -for interface, content, etc..- or when we need to define new languages.

• Language selection. This is about choosing the right language for each page request, which is currently done by the locale module and somehow, shared by i18n module. But if we want to have languages used by more than one module, the basic language selection should be built in into the core, and then calling some functions in the core modules when enabled.
• Query rewriting. In order to select the right content depending on in which language we are browsing the site, we need to process all the queries producing listings through some language aware functions. This is already implemented with the 'query_rewrite_sql' hook, but it could be somehow extended and fine tuned to have more options when building the pages.

Note: The problem here is that, to have a powerful and clean query rewriting mechanism, we'd need to pass along some more information like 'what we are selecting' and 'what for'. I.e. we may need to apply language conditions for a node listing in a block, but not for a node listing for the content administration page. Guessing from the current path and from the query itself -which is currently the only way- is somehow 'hackish' and very error prone, not to say very difficult and only for regexp 'wizards'.

• Basic localization. This is the simple 't()' function, which is quite straight forward and convenient. The problem here is having a big module, which you need to have enabled for that simple function to work, but also provides some other features not really needed in day to day operation, like strings and language management...
• Language aware objects. All the objects holding or producing some translatable information -blocks, menus...- should have at least some built in mechanism through which the output can be translated. The basics is adding a language field to each of them, which wouldn't have a noticeable performance impact.