Yes, it is really important that a programmer can see clearly when a trait method is being overridden - just as it is important that it is clear when an inherited method is being overridden.
I agree with Dr. Black on this point, but this is just language theory and not implementation details. It can be argued that reading the source provides this feature. Dr. Black goes on to say ...
Similarly, I agree that if the normal Perl environment does not provide good programming tools, then the implementation of traits for Perl ought to have done something to make it clear that a class method was overriding a trait method.
Perl::Critic is a tool in the modern Perl environment that provides this, so therefore we don't have to resort to something more drastic. You however seem to reject that in this statement ...
I suspect (though I can't prove) that many Moose developers aren't using Perl::Critic and thus aren't likely to benefit from this, thus, I agree with the traits researchers that the safety features should be in the language (or library) level rather than pushed into external tools.
Your conclusion (obviously) leans toward your desires, but I could just have easily had said "if they are not using Perl::Critic, they should be". If people are not willing to use the tools provided them (for free) then why should the core Moose team go out of their way to do still more work simply because someone chooses not to use another perfectly good tool?
In the end, and I have said this before, I think you are overusing roles.
While roles are an excellent replacement for multiple inheritance they possess many of the same (or similar) dead ends and pitfalls if used too heavily. It is my opinion is that using the alias/excludes feature is a code smell and that more than 3 roles being composed into a single class is a mild code smell that if not watched careful will turn into a full blown stink.
These are my opinions in the end so you can take them or leave them, but they are founded on many years of using roles in several big work projects, many CPAN modules and countless discussions had with others on IRC. I have probed the theory, but I have lived the practice.
I don't know that this will necessarily cause movement on anyone's part, but it's nice to know I wasn't totally insane in my reasoning
I think at this point, the movement needs to be yours.
You will note here that any new features for Moose must first be vetted through a MooseX module. At this point (thanks for rafl and others in the Moose team) role composition is now very hookable and you should find it much easier to create a MooseX module to so this now.