Ethiopia - Laziness
This is hardly untrodden terrain, and I could undoubtedly have adopted others' solutions, either commercial or Open Source. But there's always some personal benefit to reinventing the wheel, and sometimes you have to indulge the lazy feeling that it will be easier just to do it yourself than to evaluate several existing options and pick the best. (This is where pro bono meets pro ego.)
In the end, HTML code is more comparable to assembly language (like MOV R1,R0) than it is to a high level language where you'd say something more like This = That. Just as most programs are not written in "object code" that a computer can actually run but are written in "high level" languages that are translated to object code, in order to make them easier to write and to read, I've moved towards treating the HTML that your browser sees as a sort of object code that is produced by a translation program that reads 'markup independent' source and spits out formatted pages.
Recapitulating ontogeny, my first approach to this was a macro processor. I wrote a Perl script that read a source file, looking for :FnName(args) markup. It then looked up FnName in a symbol table and replaced the markup with the result of passing the args to the Perl function. I used this to do things like build a standard top of page header, with boilerplate site branding text and a localized context menu (parents and children of this page) in a standard form.
I wrote a tiny little Delphi application that monitored the "source" directory for changes (I still use a flexible and configurable descendant of that original little change monitor) and ran the script to update the object directory automatically. This was great. I could change the source (I still write my HTML by hand, in the Delphi code editor) then toggle over to a browser and refresh to see the changes.
My macro processor increased legibility by moving a lot of boilerplate out of the leaf page source files.