Although actual implementation details are still forming around the pieces we are trying to implement for the Drupal 6 core i18n feature set (which will get shipped with Drupal 6 hopefully), we should define some goals which we aim for, so we see the target. Unless we work in the same direction, there will be no useable consistent i18n solution in Drupal core for people to build their sites on. So what is possible to accomplish in the Drupal 6 timeframe, and what will only be possible to implement in contrib modules?
Drupal 6 targets (AFAIS)
I think we should start with the basics: how do we identify the language to use. This means implementation of the URL handling code I discussed earlier and implementation of proper browser language detection.
Once we know what language should we display, we need to have content in that language. Nodes or their content should be possible to get marked as being in a specific language (or being language neutral). Translations should get associated with each other. This (as far as I see) will most probably get implemented with a very present i18n.module like user interface with the language code worked into node module.
After we have nodes in different languages, we should revisit how URL aliases are handled. It is a common request to be able to specify different URL aliases to translations or share them if not specified.
We need to have a (probably) generic dynamic string translation service to use for translating menu items, taxonomy terms, profile field names, etc. I doubt we will be able to deliver a taxonomy or menu module with different hierarchy/term layout support per language in Drupal 6. I believe that we should focus on providing simple interfaces to translate these user defined items, without them being able to defined different structures for different languages.
Variables are an interesting question, since they are not all textual information. The current i18n module says that we should define an PHP array with variables to i18n-ize, and then we can set them in every language independently. I say we can improve on this with introducing a hook_variables(), which would be similar in nature to hook_perm(). It would return a list of variables used by the current module (with some description), so we can provide a list to the user to choose i18n-ized variables from. This hook can also be used to provide the default values of variables which would fix a long standing problem in Drupal: that you can have different default values for your system variables in different places of your code. All this would still only give a better UI on top of the variable handling code, which itself might not be desired by you. Do you have a better idea?
A very big open question is block handling. As far as I see, the current i18n block translation support is hacky at best, and it is definitely not hitting core anytime soon. It is far from user friendly. We need better ideas. Come and tell your view on this!
How the search module will handle multilingual sites is still a good question. Do we need to have different indexes, or should we tag the extracted keywords with the language and use only one index?
What is not going to be part of Drupal 6 (AFAIS)
I don't think you are going to see different taxonomy term and menu hierarchy support for your different languages in Drupal 6.
I also doubt you will see complex translations workflow support for translations in Drupal 6. Workflow/action modules should be reused for this task, and the core modifications should be done with keeping these modules and needs in mind. But core workflow support is not a soon-to-be-seen reality.
Support for external translation tools, like automatic Google Translation helpers when you start your page translation and/or interfacing with other (desktop or web service based) translation tools will hopefully be done in contrib modules, but definitely not in Drupal core.
Shared field support in translated nodes is not a Drupal core question unless the custom content type feature will get extended with field support in Drupal 6. Therefore this might not be solved by Drupal core itself.
How can you help?
Provide constructive ideas, improve on existing ones or offer completely new (better) implementation possibilities. Technical details of the i18n collaboration will be posted soon, so you can follow the exact development process.