<pre><code>trait Quizful[T] { def fetchList: List

trait Quizful[T] {
 def fetchList: List[T]
}

// consumer side
someQuizful.fetchList

If the List returned above is mutable, what does that say about the Quizful interface?

if this List is produced on another thread than the consumer, one can have both visibility and atomicity problems - you can't know whether that will happen, unless you take a look at the Quizful's implementation.
If this List is effectively immutable (i.e. still mutable, but not changed by Customer), you don't know if it will be signaled to other Consumers that may modify it by themselves, so you can't reason about what you can do with it.
If it is described that access to this List must be synchronized, problem is - on which lock are you going to synchronize? Are you sure you'll get the locking order right? Locks are not composable.
None from the list

Explanation

Immutable data structures are facts that can be compared and reasoned about. Mutable things are error-prone buckets. You should never use a mutable data structure unless you're able to defend it and there are really, really few places in which a mutable data structure is defensible.
So there you have it - a public API exposing a mutable data-structure is an abomination of nature, leading to problems that can be worse than what happens when doing manual memory management