Although I'd prefer to have generics, the issue isn't obvious. Generics can be really hard to understand. For example here's a HashMap in Scala:
class HashMap[A, B] extends AbstractMap[A, B] with Map[A, B] with MapLike[A, B, HashMap[A, B]] with HashTable[A, DefaultEntry[A, B]] with CustomParallelizable[(A, B), ParHashMap[A, B]] with Serializable
If that's what the type system is going to end up being with generics I'd rather just cast things. Sometimes less is more.
I don't know Scala but the very basics of the language, however notation seems clear.
Class HashMap is parametrized over two types, A and B (presumably, key and value types). The rest seems to be implementation details, that play no importance unless you're going to actually use them. Just as integers are totally ordered, but unless you have use to that fact (i.e. comparing those integers), you can safely ignore that.
Same as with interfaces - if there's a interface Foo { ... } somewhere, you don't have to care your types implement it unless you're actually using it.
One problem with that idiomatic Scala code is that all inherited traits have to be declared in the same place, making the definition conceptually "too loaded". (Scala's implicits allow for something more flexible, akin to Haskell's type classes, though.)
That suggests a problem with subtyping (or, rather, with inheritance as construct for implementing subtyping), not with generics. Parametric polymorphism is a most natural notion.
