Sounds like I didn't make much sense, but you figured it out in large part. I'll try to be more descriptive. I'm in law school, and I am studing for exams this week--and I'm online during my few breaks. :-)
What I'm generally seeking is system that allows for upgrades that require little effort--and that won't clobber local configurations. At then end of all my rambling I'll state more of my "problem." But, I presently support at least a half-dozen web sites via open-source tools, and I need a fairly streamline way of keeping the software current . . .
First, a simpler CSS--which I gather is on the slate for 1.3. That would be greatly appreciated.
Second, it would be nice to have a template system where somebody non-conversant with PunBB code, but familiar with HTML could go in and quickly put together a template. I've not had the luxury of time (lately) to figure out PunBB's approach, so I apologize if the system is easier than I'm making it out to be.
The other is partly because I'm getting "spoiled." I use a wiki to manage several web sites I support. It's easier as a geek to support others when they're not asking me to be a secretary. Anyway, I use PmWiki (@pmwiki.org). It has a design goal of allowing administrators to upgrade software without clobbering local customizations--much of which is in configuration.
An example of this would be the ability to turn off display of such things as IP and forum moderators. In PmWiki they use variables such as $EnableIPDisplay or $EnableModeratorsDisplay, which are set to true by default. however, by making the variable false in a configuration file, it immediately deactivates that feature. Conversely, in PunBB, to do each of these I've had to remove a variable from a file or two. So, I suppose I'm suggesting adding a few more configuration variables that allow toggling of more-or-less optional features.
How PmWiki preserves this is that it expects all local configuration to be in a /local directory--and it never writes files in that directory. A sample-config.php is dropped in the application root directory, which then may either be deleted or line-by-line incorporated.
Additional modules are added in a "cookbook" directory, which also is never written into by an installation/upgrade. These modules are called recipes.
PmWiki also expects that administrators won't muck with its core software. It does this by allowing methods and functions to be replaced by recipes. The underlying mechanics, I believe, is by assigning the PmWiki-default function to a variable that the local configuration can change to the local function. Granted, a forum is less likely to need this level of sophistication as much of what a forum does is fairly straight-forward.
Sorry to have written so much. I think I started rambling.