I''m not sure if this is exactly what you''re after, but here it goes:

I too wrote a q3-style shader management system for an old project of mine. Although this is not exactly how - the following is a very close description on how I did things. (Some optimization details are left out for clarity.)

I had a shader class and (for each shader read in) I had an object consisting of attributes for the entire shader. This shader class also had an array of "layers". Now each layer was essentially one texture plus it''s associated attributes.

The attributes for the shader were things that affected the shader as a whole: vertex animation, culling, polygon offset - anything that was common for all the textures. Each layer (essentially a texture) was blended one after the other - in the order they were defined. Every layer had blending attributes that said how to combine it with the previous layer.

In my system I identified shaders and textures with "handles". These handles were simply integer numbers that identified them. I first loaded the map, console, hud graphics etc but "simply" logged the names of the shaders. This allowed me to combine all references to the same names and thus to the same shader object and texture (once everything was set up). After all data had been loaded I then resolved these shader names by building the actual shaders themselves - I parsed the shader scripts. Once parsing was complete I then looked for references to shaders that had no script - I assumed they were actual textures and set up a generic one layer shader for each of those. After all shaders were set up, I finally loaded all the textures. This allowed me to load up each texture and apply any specific attribute to them such as "no mipmap".

During runtime, I selected the shader (as opposed to selecting a single texture) and then rendered the geometry. The trick was that I did not directly call the graphics api to render but rather called one generic subroutine to render the geometry. This routine looked at the shader and set up the required operations needed to render the geometry. Since the number of layers could vary between shaders, plus the number of texture units on the graphics card could also vary from machine to machine, this routine decided on how many passes to make with the given geometry. Some of this "folding" into a single pass was done upon shader load time as well (and is a good way to optimize the rendering code). This routine would only return once the pass(es) were completed on the geometry given.

The loading was surprisingly quick once I optimized it all - approx 560 physical files (including zip files) totalling approx 5500 files spanning about 860 meg (compressed) - was scanned in about 2 to 2.5 seconds on a P4 1.5Ghz system. The load time could have been further reduced but I was lazy and did not implement all optimizations I had planned. I mention this since it sounds like lots of overhead but I was pleasantly surprised by the results.

Some of the omitted details pertained to optimizations that minimized state changes - but this needs not be done in order to use shaders for what you described as a "simple" bsp viewer. I also left out the animation details but that could be introduced in the above setup as well.

I think (hope) that somewhere in that mess was the answer you were looking for.