The author tries to add "ident" to Seq, and have it work automatically on native Java arrays.

> have it work automatically on native Java arrays

Correct me if I'm wrong, but he is not operating on native Java arrays at all.

He redefines Array, redefines Seq and redefines WrappedArray as a subtype of Seq. He adds ident to Seq, and since Array isn't a subtype of Seq, ident is not a member of Array ( he points that out too, and provides a solution as well. He is operating in his own "tiny parallel universe" as he says in the post. He even redefines String and CharSequence (which threw me off because isn't java.lang.String & java.lang.CharSequence already in the namespace so the conflicts etc...) Then he wants a Seq[Char] ( not the scala Seq but his redefined Seq ) to mimic the redefined String! The whole thing is quite crazy & terribly fascinating imo.

When? The author appears to define her own Array type as well:

    scala> class Array
    defined class Array

    scala> class WrappedArray(xs: Array) extends Seq // a Seq adapter for Arrays
    defined class WrappedArray

    scala> implicit def array2seq(xs: Array): Seq = new WrappedArray(xs)
    array2seq: (xs: Array)WrappedArray

    scala> new Array().ident
    <console>:13: error: value ident is not a member of Array
              new Array().ident

Arrays are not sequences, in either the standard Scala library or his condensation of it. The goal is still to define a single extension method for two unrelated types.

Well, sorta; the Array -> WrappedArray conversion relates them. The intent is to let you use Seq methods on Arrays, and that part works. But you don't also get RichSeq methods, even though you can use them on Seqs. I'm sure that seems obvious to you, but do you see how the author's intent is misaligned with the result?

I think that's the key takeaway: implicits aren't really a way of extending a library type, they just have some of the same effects. You still have to care about the distinction between the original type and the enhanced one, and that's, well, complex.

I agree. Implicits don't compose transitively (and for good reason), and that makes them complex. That's why I suggested to think about putting implicit conversions behind a compiler switch. They are extremely useful for what they are but not a panacea.