I wouldn’t call myself that. I’m just an engineer, and when people complain, my animal instinct is to seek a technical solution 
I’ll let others debate whether traits are important enough to justify language support (I’m currently undecided).
My intent here is to add some heat to anneal the problem, to test whether we’re stuck in a local optimum or if we’ve found the best solution. What I’ve seen suggested that we hadn’t. An idea came to mind that appears to address the pain points, so I wanted to test it through dialog rather than putting in tremendous effort implementing it only to discover it was a poor idea from the outset.
I appreciate that this approach is often preferable. However, for this idea, proper implementation as a package would take maybe ten times as much effort and yield an inferior and unpleasant result, so it’s a poor approach and winning the package popularity contest wouldn’t be a good litmus test. I’ll also take this opportunity to point out that approaches that are optimal for packages aren’t always optimal for language-level solutions. Brainstorm/debate/rubber duck debug seems more appropriate for now.
Speaking of which, through this rubber ducking I found something I legitimately dislike about this proposal. Take the idea of dispatching on a container’s element type:
foo(A::AbstractArray{E}) where {E<:ElType} = ...
Naturally we would wish to extend this idea, to be able to dispatch on the traits of the element type. But this proposal offers no such mechanism. 
Maybe :: could be used?
foo(A::AbstractArray{E::ETr} where {E<:ElType, ETr>:ElTraits} = ...
I can’t say I’m a fan of this syntax though.
Also, by this proposal we’d be able to express vararg traits like so:
bar(x::X::XTr...) = ...
but there’s currently no way to express this using Vararg or NTuple. It could be expressed as:
bar(x::Vararg{X::XTr})
Still, the syntax irks me. It doesn’t feel right.