No, I don’t think Holy-traits are seen as the “solution”, merely a stop-gap pattern until a time when traits are implemented at a language level.
Yes, I too think that traits and multiple inheritance for abstract types in which types can be added after creation are essentially identical. Of course, the latter is a bit of a mouth-full and would need a name: “trait” is a good one. In particular, if we semantically separate them from “interfaces”/“protocols” as you seem to suggest in point 3 and as I suggested above. Also, once you add interfaces and have a correspondence of them to abstract types, I think point 2 is needed. Or it would be a bit strange to have a type which implements the interface but is not a subtype of the corresponding abstract type.
And, yes, I also agree that in the end there should be one “dispatch system” and not some on types, some on traits, some on …
Last, I still think that traits of several types would be good to have: some interfaces in a multi-dispatch world will involve several types and it would be nice to encode them as a trait. To translate this into MI-speak, it would mean to add a supertype to a type tuple, say Tuple{Int,Float64}<:SomeAbstractType.