I think the simplest answer would be to have a hook_node_title() or similar that takes either a nid or node object, and returns the human-friendly string for the node. The simplest case would just return $node->title, and in fact that could be the default behavior of no *_node_title() is defined. If it's defined, that function can return a semi-unique string based on the node however it likes.
This sounds a lot like an object-oriented design pattern where the node object's data is private and has to be requested through accessor methods. This is the second time in two days where I've realized that Drupal is moving towards implementing its own object system, if only a rudimentary kind. At the risk of hijacking this thread and starting a total flame war: is it time for Drupal to embrace the OOP paradigm? (Don't bother sending me the link to the page on api.drupal.org - I've read it) People want CRUD functions for everything. People want accessor methods that inherit from a base class. Some people (e.g. me) want an O/R mapper to make life easier. Can we graft an object system on to the structured array paradigm we already have? Is it worth it? Traditionally drupal has avoided a full object system for performance reasons. When will those benefits be outweighed by the cost of implementing our own rudimentary object system? Thoughts? -Mark "Plays with matches on the devel list" Fredrickson