I am one of the people disagreeing with (d), but i certainly do agree that openacs would profit much from having better ways to manage/store installation assets (configurations, local changes, as called in product line architectures variants and variability points).
Openacs is already quite good in managing core assets (packages, versions, dependencies) via the database. A development towards managing the installation assets over the database would be great and could certainly ease change management for installations significantly. However, to implement such product lines require architectural support and guidelines how to handle and track local modification in which situation to standardize the change management. The support should as well contain support for testing of the adapted installation assets.
Callbacks were primarily invented for disruptive control flows (e.g. in event handling, application semantics for GUIs), not for configuration issues. Be aware, that many problems we have today in configuring oacs can be handled with standard oo techniques such as subclassing. On top of that the strengths of xotcl are in terms of flexibility through mixins and filters, which are means to implement e.g. aspect oriented constructs. So, we are in a good shape to build a really good environment to handle installation variability. On the short range, callbacks are maybe a good tool to handle variability now. On the longer range, they won't make it easier for the sketched next level.