Yay. We launched a few days ago. Now it's time for another recap of lessons learned on the technology and process fronts:

 Process Learnings (AKA battle scars):

• Requirements & Design.
• I won't go into the reasons why, but we had an exceedingly shallow requirements gathering effort for the branding effort, basically comprised of (a) a handful of review sessions of out-of-the-box MOSS with the customer's style guide gurus and (b) a handoff from them to our dev team of the generic (but very detailed) style guide that applied to all internal websites. No wireframes, no screenshots, no "clean slate" approach to designing the look and feel - just a half-dozen or so generic design guidelines for layout changes and the hundreds of specs for fonts and colors included in the style guide for guiding stylesheet changes.
• Result: CSS updates were relatively straightforward - especially when using SharePoint Skinner or the IE Developer Toolbar to identify all the styles that needed updating - since we had a very detailed style guide and developers who knew it from working on other internal websites. Layout changes were the largest resource drain - since we were extending default.master, MWSdefault.master, etc., we often encountered vexing layout bugs relating to the complex nested tables in these pages. If you are compelled down a similar requirements/design path, plan for a long test/debug cycle, at least double that of one for a "clean slate" approach. You'll probably want to weigh the cost of investing time in wireframing everything out and building these pages from scratch using the minimal.master approach vs. an extended test/debug cycle. Don't forget to think about the cost per hour of the resources involved in each stage when weighing this decision.
• Testing
• MOSS is a huge product and good resources are in high demand. I'm subject to the availability bias here, but I suspect that very, very few of them are in dedicated QA roles. As a result, your test team is unlikely to have deep knowledge of the product, resulting in (1) test scripts that have enormous gaps in coverage (even those of us who are immersed in this product frequently "discover" existing features they didn't know about), and (2) innumerable misidentified "bugs" that are simply caused by ignorance of standard behavior. Mitigate both issues by sending your QA folks to deep SharePoint end user training OR tasking your high-cost MOSS expert with authoring test scripts. Run the numbers to figure out which is cheaper. Further mitigate issue 2 by having an OOTB MOSS environment availble to the QA team - a VM will do - to enable testers to confirm whether or not behavior in a customized environment is as expected. Again, run the numbers to figure out if it makes sense - how much a VM costs to setup and maintain vs. wasted developer/architect time chasing down nonissues.
• There are LOTS of odds & ends to cover in testing! Use Heather Solomon's checklist of branding gotchas to increase your coverage in your test scripts. 

Additional Technical Learnings:

• Should you create a backup of the LAYOUTS directory and modify the original (KB944105 method 1) or create a copy of LAYOUTS for each custom-branded web application and point their respective IIS sites to it (KB944105 method 2)?
• We adopted the simplest possible implementation of method 2. Central Admin and SSP admin continue to use the standard LAYOUTS directory (really, you've got to have lots of extra cash floating around if you're branding those sites); all user-facing web apps used a shared customized copy of the LAYOUTS directory. We initially had a distinct copy of the LAYOUTS directory for each user-facing webapp to allow for design flexibility (see the iterative design process above), but this made for an onerous deployment process that led to more than one perceived "bug" that was actualy a deployment error.
• Method 1 works if (a) you want to brand (and troubleshoot the branding of) SSP admin, and (b) Central Admin is installed on a non-WFE server OR you want to brand (and troubleshoot the branding of) Central Admin.
• Odds and ends.
• RunReport.aspx (List Settings > Workflow Settings > View Workflow Reports) is another branding outlier with no master page. If you need to brand this page, you could take the same approach as for the sitemanager.aspx page (see lessons learned 1).
• No load test data on the HTTP Module - it didn't make the cut in our aggressive delivery schedule. Watch for future blogs on this subject in the next month or so as we roll out another branded environment.