Loads of 404 errors in Google Webmasters Tools because i18n doesn't check node's language

Hi,

After a lot of testing and reading, I realise that this is actually an i18n bug:

My site is in 3 languages: Greek, Russian and English. Greek (el) is the default language. Language settings are set to "Path prefix only" and "Only current language". The site was built in 6.x from the start (if I remember right). The language switcher works fine, so the user experience is pretty smooth. But in this case it is not the human user that I worry about, but about Google robots....

Now I look at my Google Webmaster Tools and it shows a huge number of "Page Not Found" errors -- this is VERY BAD FOR SEO!
The pattern for these errors is that it only happens for the non-default languages (Russian and English), and the page URLs that google found look like this
mysite.com/en/Russian_title_of_some_article
or
mysite.com/ru/English_title_of_some_article
...of course these URLs won't work, but Google bots seem to find these weird combinations and as a result I have twice as many pages that don't exist than do exist -- the result of that is that while in my default language I'm doing pretty well in terms of search engine rankings for my keywords, for the other 2 languages (English and Russian) the site has been "exiled" to page 40 and even 87 of google search results. And it is well known that Google hates websites with excessive 404 errors.

So the problem is that when a URL like mysite.com/en/Russian_title is requested, if the settings are set to "Only current language", the i18n should first check what is the language of that node, then it should display the URL as mysite.com/ru/Russian_title instead of mysite.com/en/Russian_title

I thought that i18n_redirect module would fix this problem, but it didn't.

I'm kindly requesting that this bug is somehow corrected.
Many thanks!

PS: I'm running with i18n 1.6 because (as I reported in another bug report) Pixture Reloaded theme is incompatible with any i18n from 1.7 onwards. But that's not an issue here because the main issue of not enforcing the node's language is still present in i18n 1.9