My ideas for simple URL calculation involve moving the object hierarchy model in cr_items to the acs_object level. This basically means a parent_id column. Don has mentioned this, it basically could replace context_id in most cases, and well as be a more useful definition of "where" content belongs than package_id.
Right now, site_node information, including URL is stored in an NSV array. If we expand that to include any parent_id, site_node, cr_folder, etc, calculating a URL is as simple as retreiving the url of the parent and appending the url of the object to the end.
Right now, some packages do this in an ad_hoc way with an index.vuh file that figures out an object_id and returns a template. If there is a site-wide object hierarchy this can be centralized, probably handled by the request processor directly.
To allow an object to appear at more than one URL, something similar to cr_symlinks could be used.
I will be exploring how all this works in a content management context and I will try to see how it can be applied site-wide. I believe that if this type of function is enabled, it will not break any existing code, it will just allow more consistent use of pretty urls and make services such as search, categories, and notifications easier to write and to use.
