Ola, I also think that having the curriculum bar in the default master is not a good idea. However, I suggest that you write a service contract for toolbars. The service contract should, at least, support a toolbar provider operation, i.e. the curriculum bar could be provided for all labels/context that match the expression "*" (let's call this the toolbar provider expression (TPE)).
Then, a package parameter, say ShowToolbarsP, in acs-templating or acs-kernel could be used to denoted whether to display toolbars or not. A simple extension to default-master would be required in that case, i.e. if the ShowToolbarsP switch is on, then forall TPEs that match "default-master", display the corresponding toolbar. Other toolbars that I can think of are for i18n, ecommerce, etc.
Now, suppose that you need to display a toolbar (not necessarily for curriculum) in all templates of a special type, say that you want to display a user's recent history of product views in templates that are related to the ecommerce package, then you could say assign a TPE of ec-* to your toolbar and the ecommerce package would have a template that requests toolbars with "ec-special1" or "ec-special2" and so on.
The toolbars should be either read-only or both read and write (one further package parameter could be used to denote the type of toolbars to process in each template). The read-only is obvious what it means. An example of a read-write toolbar is the recent-product history (introduced above), i.e. the recent-product-history would update the user's product views history every time it is rendered.
What others think?
