CCK is becoming quite useful and living up to its promise. The node and user reference fields are not terribly useful yet, though. The Add and Reference and Form Restore modules by Artem Timofeev are great additions to the interface aspect.
By far, however, the largest issue that limits the real use of the node and user reference fields is their lack of ordinality. It is impossible to say that the relation is 1:1, 1:n or n:m (if we were really daring we'd implement an inheritence reference as well). For example, I'd like to use CCK to have a database of composers and the pieces they've written. Assuming I could work out all the interface and workflow issues that make it rather clunky to catalog the complete works of Mozart and Telemann using these tools, the real knockout criterium that prevents this from working is that there is no way to say that a piece can only be referenced by one composer (1:n). What good would the database be if it were possible to say that both Beethoven and Stravinski wrote the moonlight sonata?
So I'd like to hear what thinking others have done on the issue and who, if anyone, has any concrete plans.
Part of me thinks that the implementation of references as fields is misguided and that the whole relationships/references thing should be its own system. After all, a bi-directional reference that enforces ordinality rules doesn't really belong to just one of the involved nodes, but rather both. Or, perhaps it doesn't belong to either of them, but they belong to it. Maybe we shouldn't be sticking reference fields in node types, but rather creating reference node types (or reference types) that get configured with a left and right node type and ordinality rules.