Actually, I think we see this from a different point of view as I don't think this behavior is inconsistent. Let's say I have an Animal class, a subclass of Organism. In this class I use an Eat trait (Insect might use this, too, for example), but since the author of Organism decided (for the sake of argument) that not all living things eat, there is no &eat method to inherit. A trait might be appropriate here because I don't want to redefine the method (which I would have to do with interfaces) and there's nothing else to logically inherit from. Further, delegating this to another class might not make a lot of sense.

So now I decide that I want a Mammal class which inherits from Animal. If I want to override &Animal::eat, I need to explicitly code &Mammal::eat. Explicitly coding this should mean that I really, really want what I coded. Whether or not &Animal::eat came from a Trait or was hand-coded should be irrelevant to my desire to override it. I should not care about implementation details. Therefore, regardless of whether I hand-coded &Mammal::eat or got it from a Trait, this method should behave towards inherited methods exactly the same way. If I have a Trait method that overrides an inherited method, I as the programmer have the responsibility to know the published interfaces of the Classes and Traits that I use. On the other hand, an optional warning might be nice; I'll have to think about that.

Does that make sense? I'm not sure I explained that well.