Ethiopia - Templates
This Perl script was certainly an improvement. I had separated the boilerplate from the individual content, and I had made it easier to change design elements in a consistent way - I just had to change the macro source. But it still suffered from two fundamental problems. To start with, adding or changing even the simplest macro required modifying the Perl source. The other problem was subtler, and I didn't really notice it until I was free of some of the boilerplate pressure: keeping context menus in the individual page source means that you can't add or move pages without updating lots of neighboring pages.
My second solution is better. I use a template that contains all the boilerplate that a group of pages have in common, then pour in the actual body text and the appropriate version of any other common text, like context menus or <title> tags. The way I implemented this, a template consists of two sections - a header that defines various named values, and a body that can contain %Name% markup. Each leaf page also consists of two similar sections - an optional header that can define new named values (or override defaults it inherits from the template) and a body which will be assigned to the named value Body.
When an object file needs to be remade (because the template has changed, or an individual source file has changed, or changes to the menu structure have changed the page's context menu) all the named variables are set, and then a new object file is created by replacing every piece of %Name% markup (in the template body) with the appropriate named value.