Forum OpenACS Q&A: Re: Extensibility in OpenACS - Four Architecture Options
Whether that customization takes place in the source code or not is, to some degree, an implementation detail. But just hacking the code is always the quickest easiest way to do it - at least at first. So, the obvious first step is to get the best version control tool for your code you can. E.g., ditch CVS and investigate Arch immediately.
That way, at least you won't be artificially pushed into non code hacking methods of customization. And to me, that suggests that your ultimate designed solutions will be superior, as you will be able to learn from, e.g., refactoring 2 to 4 custom customer deployments into one unified whole, once you've learned what's important from experience.
However, I would never call code customization "Copy-Past-Modify". This implies all the wrong stuff... You should probably call it the "Customize Code and Refactor" approach, or something like that.
Frank, as far as the rest of your question about approach or approaches to use... I don't know. You seem to have a good start on thinking about possible ways to do it, and I lack hands-on experience in this. Other helpful steps might be to:
Briefly describe of all the known per-customer customizations you've ended up doing in practice.
Find out who else is using OpenACS to do SAP-like customized independent deployments of vertically integrated integrations to multiple customers. In other words, not fully custom functionality, but (minor?) variations for each customer on a specific application theme (e.g., "company intranet"). The only example I can think of there off hand are the various dotLRN sites running at different universities (except, they all tend to have OpenACS hackers on staff, which changes things). Perhaps also that semiconductor thin films equipment company that uses OpenACS - if they deploy OpenACS to customer sites; I'm not sure whether they do or not.