You do realize the futility of such questions given Turing completeness, right?
It is not about what can be expressed, but about how you express things. You do not need function literals in Scala, but it is sure is more concise and cleaner than anonymous classes in Java. You do not need traits in Scala, but it avoids code duplication or the overhead of wrapper classes or proxies in Java. You do not need case classes and algebraic pattern matching in Scala, but it is far more concise and less error prone than having to write the obscene amounts of boilerplate you would write in Java.
Scala, with its “type-level programming”, crazy operator overloads and weird DSLs, is at a similar precipice as C++ was back when people started doing insane stuff with template metaprogramming (around the time of Alexandrescu's “Modern C++ Design”, 2001 maybe?).
Unfortunately, I don't think many Scala users were around at that time or in that community, so lessons of the past might be learned the hard way again.
There are many encouraging signs too, though, toward better and simpler practices. We'll see which way things go.
Yes, I guess I answered the letter of his question... but I personally wouldn't use collection types indexed by a size unless (a) I really really needed to be sure about this particular invariant (b) there was a bit more sugar and automation. In most cases the added verbosity and complexity involved would not generally be a win over just using an assertion. However, it is nice to know you have the option of static enforcement should it be desirable.
That is not a simple type. And people who still remember the original Pascal will know that you do not want to encourage people to make the size part of the collection type. And it doesn't buy you much if you cannot prove at compile time that the type you use to index into the collecton cannot overflow the collection bounds. Use Ada if you need that.
It is not about what can be expressed, but about how you express things. You do not need function literals in Scala, but it is sure is more concise and cleaner than anonymous classes in Java. You do not need traits in Scala, but it avoids code duplication or the overhead of wrapper classes or proxies in Java. You do not need case classes and algebraic pattern matching in Scala, but it is far more concise and less error prone than having to write the obscene amounts of boilerplate you would write in Java.
And so on.