Issue 1:
This issue was previously reported as bug at codeplex, now trying to submit as suggestion.

Below, the Collection.model field is supposed to accept type of TModel rather than instance of TModel:

class Model { }
class Collection<TModel extends Model> {
model: typeof TModel; //Error: Could not find symbold 'TModel'.
models: TModel[];
}

class MyModel extends Model { }
class MyCollection extends Collection<MyModel> {
// This is what we want
model: typeof MyModel = MyModel;

// This is what we don't want
//model: MyModel = new MyModel;
}

var coll = new MyCollection();
var modelType = coll.model;
var newModel = new modelType();

Use of typeof keyword seems to be appropriate here, but compiler doesn't understand typeof of generic type. If we said model: typeof Model; it would compile but that is not exactly what we want.

Some of the workarounds we found are the followings:

class Model { }
class Collection<TModel extends Model> {
model: { new(): TModel; };
models: TModel[];
}

class MyModel extends Model { }
class MyCollection extends Collection<MyModel> { }

and

class Model { }
class Collection<TModelConstructor extends typeof Model, TModel extends Model> {
model: TModelConstructor;
models: TModel[];
}

class MyModel extends Model { }
class MyCollection extends Collection<typeof MyModel, MyModel> { }

Feature suggestion is to allow typeof generic type.

Issue 2:
This issue tracks our plans and discussion around the current situation with package typings.

Internally, we've been talking about how to better package, locate, and discover typings for packages which do not include their own typings.

The issues which arise around packages and their typings include:

Reuse - the ability to take typings written for long-ago TS (ambient declarations) and continue to use them with little or no modification

Dependency management - typings typically depend on the same things that their host js packages do - and usually on their typings, not their js.

De-duplication and flattening - Deeply nested typings (with potentially duplicated dependencies at multiple levels) lead to a lot of duplicated work in the compiler, and could result in longer build times. We'd like to head this off before it becomes an issue in practice if possible.

Discovery - if I'm using package the node package bluebird, how can I find types for it without skipping a beat?

We've spoken with @blakeembrey and his plans for typings (a tool to replace/improve upon tsd). We believe that we're both setting out to solve a lot of the same problems, and we'd love to help build much of that functionality into the compiler and language service to create a seamless development experience.

We've come up with a number of improvements to pursue on our end, including:

Package scopes (#4913) to help with typing reuse and isolation issues

Extending our node module resolution for typings to have a concept of a fallback-typings package - a package which provides typings for a correspondingly named package. (For example, typed-debug can be installed and provides types for the debug module.)

Reducing the volume of type checking done for packages (ie, don't typecheck them)

We want to make it seamless for users to use typescript with their existing tools and processes, and this includes their dealings with typings. Ideally, we want users to be able to npm install their dependencies as they already do and have everything "just work" without further steps or instructions.

Tagging @mhegazy @ahejlsberg @vladima @DanielRosenwasser and probably many others who should get tagged for discussion.

I'm sure I've forgetting things from our discussion earlier, so feel free to chime in with the relevant conversion points I've missed.