Ben's already looked into stubbing in hooks for a service-contract based navigation gizmo. It would make replacing the current context bar semantics with something different much easier. This is a new wrinkle on what we're talking about, leading to a synthesized picture looking something like:
1. A SC-based navigation gizmo builder is called by the package's page scripts (vs. today's glued-in calls to ad_context_bar). It would default to today's ad_context_bar. Making this SC-based makes it easier to imagine gluing in different navigation gizmos into different subsites, for instance. One possible substitution would be an implementation tracking a *real* breadcrumb trail rather than the sitemap-derived navigation bar that's arbitrarily built today.
2. The returned gizmo is passed as a property up to the master template, along with some of the other stuff we're mentioning.
3. The master template massages the navigation gizmo into whatever format the site designer's looking for.
