However I am saying that this power comes at a constant development cost in terms of figuring out what is happening, why, where and when. This is not something that is visible in the statistics that you quote. This is something that shows up gradually when someone is lost in code and wandering around saying, "Where did foobar() get defined again, and how do I get it again?" Or alternately when you are wandering around saying, "I have a foobar(), but it isn't what I expected it to be? Why not? And where is this coming from?"

These are issues that arise in the single inheritance world as well, although becuase the model is more well known/understood, it is less of a problem. The triats papers stresses that development tools are very helpful parts of the traits refactoring process. This is an obvious need for any new model that is introduced to help the adoption of it. Also things like meta-information left over from the compiler are important as well as tools to view that information. A great example of this is the .NET CLR which makes excellent use compiler meta-information and allows access at runtime to make highly detailed reflection a simple an efficient thing (at least more efficient than Java's reflection). There was a time when people didn't think that there was a need for run-time type information in C++, but few programmer today would want to live without it.

Also if you go up to the link I had on mixins, you'll find that my opinion is somewhat finely nuanced. I don't think that mixins (or traits, or roles, or...) are Evil Incarnate. I just think that they impose a cost for their benefit, and the cost is one that needs to be carefully understood before deciding to splurge on their usage.

I didn't mean to imply that you did think they were evil incarnate. I think we both agree that they have their place, and that they should only be used by those who know when and most importantly when not to use them. But those lessons are sometimes very hard to learn and live with, so my feeling has always been that spreading the knowledge of when to use them (and when not to) is only helpful to the programming community at large.