"I was more thinking of when you want to slightly change the behaviour of a package in a client site, but in a way that's not suitable to be committed to cvs. If we had an OO design...."
Isnt the thin object system that Oacs provides enable us to do exactly that. We might run into awkward code if you have to do another level of inheritance , but how often would you need that?.
One the other hand TCL was meant to be used as a glue and to do simple things. I believe the API and the framework that we have in Openacs provides us a way to get around the limitation that we meet with TCL.
But to get to the point of using the framework to solve problems that generally arise we encounter a learning curve of the framework. Although Openacs provides a certain degree of abstraction IMHO its not enough. This is where I think Ruby/Python helps and makes abstractions more obviuous thus leading more code reuse and easier understanding of the framework.