[Open]ACS 4 is no better in this regard than earlier versions of the ACS, and you've identified a real problem. Programmers build these "by hand" with some help from procedures that know something of the site map structure. As you've noticed from [Open]ACS 3.x the nav bars aren't consistent in how they build up the string of nav links (the "crumbs").
This is largely due to the fact that they're built "by hand" by programmers who don't always do things consistently. As the toolkit's matured, the nav bars have become more consistent but that's due to sweaty work, not automated help.
For my birdnotes.net site I developed a scheme that works very well for automatically generating the proper nav bars, but it depends upon - and generates - very, very ugly URLS with a lot of garbage encoded into them. We need a better scheme, long-term, for OpenACS 4.x and I'm open to suggestion.
Despite the ugliness of the URLs my scheme generates, the basic notion
I implemented is easy to use. Each time you enter a page you do an "update_context_bar" with the variables needed to regenerate the page, and there are procs to generate links with popped-off context bar data
so pages automatically point back to where you came from, rather than a fixed set of links. Something along these lines could interact with
ad_page_contract (which could generate the context bar) in the more general environment implemented by the ACS in the days since I wrote my hack (based on ACS 1.x).
Cookies are invisible but users don't like cookies and we really only want to use them for users who are logged in. Encoding short values in the URL that map to session state data in the db might be the most practical approach. Ugly URLs like I use on my birdnotes.net site are
not an acceptable solution for a general toolkit, unfortunately.
