You are, unfortunately, making the same 'mistake' that Joses approach has had since the beginning:
There is *no* holy grail. All our i18n sites differ so much in what they need that they can never use the same codebase.
I didn't mean to imply that it was the "holy grail". Um... wait, didn't you start this discussion about finding the holy grail for i18n support for drupal? :D (heh)
*this* cannot live as turnkey in core. It can only ever live in core as APIS that offer miodule developers to build translation and so interfaces.
Why not? Aren't those the same? How do you accomplish one without the other?
My post is not "just a wild idea" to hack current systems up into smaller chunks and that be it. Its four years of Drupal-i18n experience that I compiled into a final proposal :). ... to illustrate my reasons for disliking the monolyth apprroach.
I don't doubt your intelligence or your experience. Only mine. :) How would your proposal address these challenges: 1. Storing the multi-lingual content in the DB (true support, not just making new nodes) 2. Making it easy for contribs to support multi-lingual nodes (again not just new nids). What if these contribs create new node types? I don't think we can expect all contributors to create their own multi-lingual implementations. (shudder). Ben.