Refactor nodereference to handle multilingual content?

In #301736: Multilingual support for nodereference we tweaked the behaviour of nodereference fields when nodes are being translated. But significant issues were left unaddressed. What do we do when a new translation is created, when an existing translation is deleted or marked as needing updating, etc.? I'm wondering if we need a deeper solution to the problem of references to multilingual content.

What is a nodereference? Almost always (or effectively always?), it's a relationship between two pieces of content--not between particular translations. Consider a use case with two types of content, companies and products. What's important is that a product is associated with a company--not that some translation of the company in a given language is associated with some version of the product in the same language.

So, in most cases, what we in fact want to track is a relationship between translation set, which are identified by the nid of the source translation. So a node reference should indeed always be a relationship between two nodes identified by nids. But in the case of translation sets, I suspect, these should be the nids of the "source" translation--or, in other words, the tnids shared by all members of the translation sets.

By having a single relationship - translation set A has a reference to translation set X - we would avoid the major headaches of having to track and update many different relationships between particular translations. We would also avoid data duplication and redundency. And, in the fallback case of a single-language site, we would have what we've always had--a reference from one node to another.

But what would this look like in practice? It would require a significant refactoring of nodereference, and possibly of field handling in general. I'll give this some thought next week and see if I can sketch out an outline. Ideas or feedback meantime would be great!