The way I see it, we need 3 things:
1. An inexpensive way to get a URL for an object. The /o/ trick is the best solution to this I've seen so far.
2. Where in a hierarchy of object this belongs. For a forums message, it would be the path to the forums package, but also include the forum. For a logger entry, it would include the logger package and the logger project.
In general, I want to move towards a data-centric design rather than a package-centric design, so objects don't belong to packages, but to any container - a folder, another item, etc.
3. If we want to present the item, we also need information that pertains to the particular object type, to get the name of the object and other relevant pieces of information. These other pieces of information may even depend on the object type.
(Branimir told me a trick, where a "presentation" column was stored in a central place, such as acs_objects. This column contains whatever the object type decides to store there, to use when presenting objects of this type, without hitting the type-specific tables.)
Thus, we need to talk about how this fits with the road-map.
For 5.1, if it solves an important immediate problem, I'd be okay with this solution,
But for 5.2, I'll want to revisit and think about a proper solution that will work for a data-centric approach. We should discuss that as soon as we've pushed 5.1 out.