The implementation of ContextL relies heavily on the CLOS MOP, and among other things on runtime class redefinition and corresponding updates of class instances. You can find the details how the class redefinition machinery is used in cx-partial-class.lisp at https://github.com/pcostanza/contextlTo the best of my knowledge, ContextL is one of the most efficient implementations of context-oriented programming (as compared to other implementations of COP for Java, Smalltalk, and a few other languages). This is because there is enough machinery in the CLOS MOP that provides the necessary dynamism and efficiency at the same time.ContextL has been used in production, so should count as relevant.
Removal of features can lead to more efficient implementation strategies, but also leads to less expressivity. It’s always difficult to draw a good line between what is good for most cases, and what is necessary for some. I, for one, am happy that CLOS MOP provides this amount of flexibility. There are enough OOP systems / languages with reduced expressivity (including ISLISP, Dylan, and some Scheme implementations) that we don’t necessarily need another one.It has already been pointed out in this thread that you can always revert to the much more restricted defstruct. Maybe that one is too restrictive for your taste, but again, it is difficult to draw a good line between restrictive and expressive, and no compromise will make everybody happy.
I think CLOS could be even more flexible, without loss of efficiency, but that’s a different discussion.