Lambda the Ultimate

Ah, that's a good way of looking at it. My nested types are like Java's "static" inner classes. (The language is a simple tree-structured data definition language, like JSON, so I don't think it even has enough expressive power for a non-static nesting to even be useful.)

However, I neglected to mention a feature of the language that makes the "No" choice a little messier. Sometimes, types are implicitly defined. For example:

type Thing(K,V) {
  Leaders: {    // type is specified inline
    Key1: K
    Key2: K
  }
  OtherKeys: List(K)
  OtherValues: List(V)
}

This desugars into:

type Thing(K,V) {
  Leaders: Leaders(K)
  OtherKeys: List(K)
  OtherValues: List(V)

  // compiler automatically generates this
  type Leaders(K) {
     Key1: K
     Key2: K
  }
}

I like that the type specified inline automatically captures the type environment. So when desugaring, the generated type definition needs to be type-parameterized. Not a huge deal, but this is where the type-capturing option comes out a little cleaner.

I do agree that the capturing option is more intuitive given the syntax I used. But another way to look at it is that my "type" construct actually defines a type and a namespace of the same name. So:

type Map(K,V) {
   elements: List(Pair(K,V))
   type Pair(K,V) {
      key: K
      value: V
   }
}

Could be seen as a condensed form of:

name Map {
   type (K,V) {
      elements: List(Pair(K,V))
   }
   name Pair {
      type (K,V) {
         key: K
         value: V
      }
   }
}

Again, I agree the capturing option is conceptually simpler. But for many uses, it ends up being slightly redundant (i.e. when the nested type doesn't use the outer type parameters).

Is that not similar to the problem of variables captured by a closure? You want to capture only the variables used in the closure.

Yes. For references to Count within Map, it works like variable capture in closures. No matter how many type parameters are actually captured, they are all currently in scope and so they don't show up in Count's type parameter list.

But for references to Count from outside of Map, those captured type parameters are no longer in scope and thus must be specified. One way of doing this is to be uniform and plug in type arguments for the outer type: "Map(Int,Int).Count".

The disadvantage of doing that is that we must provide arguments for all of Map's type parameters even though Count doesn't use all of them. That's why something like something like "Map.Count(Int)" is attractive.