I've been quiet because I thought I'd solved this, but apparently not.
Here is the current state of the play:
SERVER: Centos+Litespeed VPS, WordPress 3.1.3
WordPress multisite network of 26 blogs (1 main site, 25 sub-blogs in sub-folders, including one prototype blog).
There is a separate WordPress blog on the same server under the same domain in a sub-folder using a different database.
The Super Cache plugin is network activated on multisite, and each sub-blog configured. Htaccess method is used, but an earlier trial of using php made no apparent difference to the non-serving of supercached files.
Garbage collection is set at 172800 secs.
Preload is set at 43200 minutes
sample URL of sub-blog: http://www.travelsignposts.com/Germany
sample RL of sub-blog post: http://www.travelsignposts.com/Germany/food/steckerlfisch-oktoberfest-food
sample URL of sub-blog page: http://www.travelsignposts.com/Germany/map
URL of separate blog: http://www.travelsignposts.com/wordpress
Sample URL of separate blog post: http://www.travelsignposts.com/wordpress/classical-music-and-operas/passau-music-festival
This position is the same as that prior to my pre-load activities listed under "Recently".
All posts and pages are supercached.
All blog index pages are served from supercache.
The multisite blog network Super Cache uses .htaccess to serve its files
Main blog: Index page and pages supercached (posts pulled from sub-blogs redirect to respective sub-blog posts as designed: SiteWideTags plugin).
Sub-blogs: Index page served from supercache. Posts and Pages not served from supercache (supercached file not found so new one created).
Separate blog: Supercache functions as normal, all posts and pages served from supercache. Supercache uses php to serve its files.
The position was the same as outlined above, when I tried pre-loading all sites in the main network one by one. This resulted in the supercached files suddenly being served as they should be.
However, a few hours after all the sites had been pre-loaded (around 12,000 files, three days later), Supercache stopped serving files from the supercache and the position regressed to the current position. This resulte in an approximately threefold increase in CPU load.
It has been noted that the url used in the supercache directory uses a lower case as opposed to the upper case in the WordPress file, i.e.
Actual URL: http://www.travelsignposts.com/Germany/food/steckerlfisch-oktoberfest-food
Supercache URL: /home/MYACCOUNT/public_html/wp-content/cache/supercache/www.travelsignposts.com/germany/food/steckerlfisch-oktoberfest-food/index.html
The argument against this is that the blog index pages (which are served from the supercache) also have the upper case country name in them, and a corresponding lowercase URL. Similarly, prototype blog has a lower case folder name and exhibits exactly the same behaviour as those with an upper case name.
So, that's where I am at the moment. If anyone's got any ideas I'd be pleased to hear them, as I'm struggling a bit. Having had an albeit brief experience of the promised land when supercaching worked, I'm determined to get it running...