One big change in the ACS, starting with 3.3, is that all content will be served through a central procedure.
(that's a bit of a lie, the facility is there but the whole toolkit won't be ported to it by 3.3, new stuff will be using it, though).
They're also moving to a document model where titles, navbars and the like will be built as document parts. The Adp page which these are bound to can do whatever it wants to do with the various parts, they're no longer put out by Tcl ns_write or ns_return 200 statements.
This model doesn't quite get the ACS to a place where stuff like Mike's talking about is possible. But it is a step in that direction. The problem with the ACS document model is that the code for each page is still building navbars and titles and all that "by hand", building up an explicit list of links for the context bar, setting hard text in the title, that kind of thing.
Mike's suggesting a greater level of abstraction, and having just gone through the exercise of implementing a navigation model quite different than the standard ACS way of doing things, I can attest that an even greater separation of the generation of navigation and other document header parts than aD's implemented for 3.3 would be useful.
Of course, it only took me a couple of hours to hack together the code to automatically generate the navigation tools the customer wants, along with about a half day of hacking out unwanted <h2>bloody titles</h2> that are glued in the text (this last bit disappears in the new aD model, in 3.3 I would always set the title to "" no matter what the code told me to do). But a more complex navigation model would be a pain in the ass to implement, involving minor rewriting of each and every page in those ACS modules used in the project.
It shouldn't be that hard for users to customize the ACS in this area.
