The language support provided by the i18n modules Drupal 5 and (it seems) from the dev. version of Drupal 6 makes makes it easy to maintain content in multiple language versions, but doesn't seem to handle multilingual users very well.
The menu settings for a multilingual Drupal should be able to choose between:
1. Show only nodes in your default/preferred language (suitable for monolingual users and for sites where all content has been translated) This hides content from languages other than your own.
2. Show all nodes and translation of nodes (especially relevant for admins) This creates duplicates of all translated content in menus which makes it very confusing to navigate.
3. Needed: Show content in your preferred language, and display alternative language version(s) in the menus if no translation have been made (yet)
The menu settings described in #3 may be useful for any site with multilingual users and not 100% translated content. It also makes cross country collaboration easier in situations where may read several languages, but prefer to write in one language. In countries like Switzerland, Belgium, The Nordic countries and Canada, where it may be relevant to run partially translated multilingual web sites, without cluttering up the menus with lists of all nodes, regardless of language. In some cases it may also be applicable when maintaining mixed sites with US/UK English.
The language settings of the site my team is building now may illustrate the point why I think support for setting #3 is needed: We are building a Norwegian language site. The language situation in my country is somewhat peculiar, since there are two versions of the written Norwegian language (called Bokmål and Nynorsk), all Norwegians are perfectly able to read both languages. All government agencies are obliged by a law from 1885 to provide at least 25% of the web site content in either of the language versions, any citizen have the right to get written communication from government agencies in their language of choice, and in many cases, many categories of content must always be provided i both language versions.
I have also tried to implement a solution for #3 in drupal 5. Maybe a more experienced PHP programmer than me may be able to incorporate this SQL-fragment as a patch ?
-- SQL fragment for removing duplicates of translated content in menus
-- tested in drupal 5, localizer module
SELECT n.nid, n.title, b.parent
FROM node n
INNER JOIN book b ON ( n.vid = b.vid )
LEFT OUTER JOIN localizernode loc ON ( loc.nid = n.nid )
WHERE loc.nid = n.nid
AND loc.pid = 1 # 1 is an example pid value, should be a php variable
AND loc.locale =
(CASE WHEN EXISTS
(SELECT l.locale FROM localizernode L
WHERE loc.pid = 1 ) # 1 is an example pid value, should be a php variable
THEN 'nn' # language code for the user's preferred language
ELSE 'nb' # language code for alternative language version
END )
;
Hopefully there are other solutions as well?
Other issues I have noticed in Drupal 6's language support:
- The option "Language neutral", should be removed or made optional. I cannot think of any situation where it is useful, except for image nodes or perhaps pages with computer code or maths. A page is nearly always in one and only one language, and there is no such thing as a "language neutral" page. There may be some uses, but it would be better if this was an opt-in choice.
- The settings for left-to-right or right-to-left should be stored in the language profile and not be displayed as a settings option, since it is never an option for users to change their language to another text alignment.

Comments
patches, built in stuff
I am sure the i18n module developers welcome patches against the module, and Drupal 6 is definitely accepting patches.
About the language neutral stuff, you might not think of a site where no language support is turned on yet. You think we should save nodes with English associated, or without associating a particular language. We do the latter now.
The right-to-left and left-to-right choices are settings the admin can change because we only have a list of some possible languages, and we probably don't have a complete list of all languages of the world. For users to be able to set their custom language up correctly, we need to provide this setting, as we don't have language profiles for all languages possible.