I think it makes sense to think about traits and interfaces/protocols as separate things.
A trait, I understand as a set of types, which can be used for dispatch. Using this definition, an abstract type indeed encodes such a set. One thing traits need to make them useful is that types can be added to them after creation; and this is where multiple inheritance would fall short (as the supertypes of a type are fixed at its creation/definition). Holy-traits are a pattern to create trait, which is extensible after its creation. Things which need to be figured out concerning traits are inheritance, intersections and such and what that means for method resolution; presumably set operations will do.
Now, as I see it, interfaces/protocols are a way specify which types belong to a certain trait: say the trait of all types supporting iteration means that each of its elements has to have methods start, next and done defined. The specification of these interfaces can be a bit intricate, this was discussed in #6975.
I think it is useful to keep a mental distinction of above two concepts even though they are quite intertwined.