In response to Rossberg's challenge to encode the following:

 
signature S =
sig
   structure A : sig type t; val x : t end
   val f : A.t -> int
end
 
structure M =
struct
   structure A = struct type t = int; val x = 666 end
   fun f x = x
end
 
structure N = M :> S
 

In Scala, the above becomes:

 
type S = {
  val A: { type T; val x: T }
  def f(arg: A.T): Int
}
 
val M = new {
  val A = new { type T = Int; val x = 666 }
  def f(arg: Int) = arg
}
 
val N = M : S
 

And using N.f on N.A.x is even well-typed, but still encounters the same problems with evaluation I mentioned earlier. And yes, the type N.A.T is hidden:

 
scala> val x : Int = M.A.x
x: Int = 666
scala> val x : Int = N.A.x
<console>:7: error: type mismatch;
 found   : N.A.T
 required: Int
       val x : Int = N.A.x
                         ^
 
scala> val x : N.A.T = 42
<console>:7: error: type mismatch;
 found   : Int(42)
 required: N.A.T
       val x : N.A.T = 42
                       ^
 

As for how Scala, solves the double vision problem, I would look at the work on νObj, and the forthcoming paper on Featherweight Scala.

Update: Looking more closely at the definition of "double vision" as defined by Dreyer, the Scala implementation cannot currently handle his motivating example. I will need to think about how the example works in Featherweight Scala, which to my knowledge shouldn't have a problem with at least defining the type signatures. I think the short answer is that νObj and Featherweight Scala (the non-algorithmic version) solve the problem in a vacuous fashion, as the type checking problem for them is undecidable. Scala proper possibly could resolve the problem by using a less restrictive cycle detection algorithm.