This particular class was a more-or-less straight port of what I’ve done with my students in Java8, so there are no extension methods and the best you can do are default methods on interfaces. If you were engineering this thing specifically for Kotlin, then you’ve got an interesting design case to be made for extension methods vs. default methods on the interface. The benefit of extension methods is that they keep the interface slim. The benefit of default methods on interfaces is that you can specialize them, when appropriate, to improve performance.
Another purely stylistic question, of course, is how much you care about interoperating with Iterator<T> and other such things, versus having all the usual functional methods on lists (map, filter, foreach, fold, etc.). From an educational perspective, you want the students to build everything up from scratch themselves, thus they know how it works because they wrote it. That’s totally different from what you’d want in a production environment.
As to the argument in favor of having an IList interface (which we don’t bring up until a few weeks into the class): this allows for lazy lists and eager lists to coexist without most clients having to know or care which one they’re dealing with. In my class, for next year, I’m planning to take the somewhat weird tactic of initially doing no class inheritance whatsoever. Just interface implementation and you can share code with default methods. I’ll bring class inheritance in later in the semester. This makes for another argument in favor of having default methods in the interface, namely that they’re forced to be implemented in terms of the public-facing methods, since they cannot see the private implementation.
Anyway, the “wart” in this case was the type erasure aspect of Java, which Kotlin inherits. The idea that the JDK libraries represent another wart really depends on your perspective. Nobody says you have to use them, unless you’re trying to interoperate with some other library that requires them. Kotlin tries to strike a balance by giving you a shiny functional veneer on top of the traditional Java list classes. This seems reasonable for many things.