Issue 1:
If you have the following code:

interface Api {
a: string;
o?: string;
}
var v = { a:'s', i: 5 };
var u : Api = { a:'s', i: 5 };

v will be automatically types based on its structure, while u will be typed according to the specified interface Api. As a result the compiler will give the following responses to the following expressions:

v.a // string typed

v.i // number typed

v.o // compiler error not in the automatic type

u.a // string typed

u.i // compiler error not in the interface

u.o // string typed

I would like support for something that gives me the benefit of both, an automatic type, that i can give it a list of implements, perhaps using a syntax like this:

var s : <G implements Api> = { a:'s', i: 5 };

that will give me the following responses from the compiler:

s.a // string typed
s.i // number typed
s.o // string typed

The advantage is that i want to specify the interface so that the compiler can indeed check that i follow whatever is defined in the interface, but still allow me to use things that are not mentioned in the interface.

This is especially useful when i am using an interface with indexer like this:

interface IMap<T> {
[name:string]:T;
}
interface IPolicy {
dealWithXXX: () => void;
// more complex policy options
}
var policies : <G implements IMap<IPolicy>> = {
policy1 : { dealWithXXX: () => {
// To one thing
} },
policy1 : { dealWithXXX: () => {
// To other thing
} }
}

Here i want the interface to guard me so if i add some additional requirement to IPolicy it will be checked for all the different policies by the compiler, I also want to use the indexer as an getter for selecting the correct policy by name, last i also want to select specific policies as attributes for example for selecting a default policy

var currentPolicy = policies[policyName] || policies.policy1;

Currently the only cumbersome way to get that is using the following code (that IMHO is not maintainable):

interface ICurrentPolicies: extends IMap<IPolicy> {
policy1: IPolicy;
policy2: IPolicy;
// continue list here all diffeerent policy names
}

var policies2 : ICurrentPolicies = {
policy1 : { dealWithXXX: () => {
// To one thing
} },
policy1 : { dealWithXXX: () => {
// To other thing
} }
}

Issue 2:
Here is a common scenario for my open source projects:

module-a (depends on module-b)
├── bower_components
│ ├── dt-foo (depends on ../dt-node)
│ └── dt-node
│ └── node.d.ts (v0.10)
└── node_modules
└── module-b
└── bower_components
└── dt-node
└── node.d.ts (also v0.10) <-- conflict!

A slew of errors result, "Subsequent variable declarations must have the same type," etc. This is, of course, because we are referencing node twice at two different paths, which TypeScript sees as totally different modules, even though they are exactly the same modules, even the same version. As such, it thinks we're trying to redefine things that are already defined. I get it.

What I don't get is how to solve the problem gracefully. I've gotten around it, but I'm not happy with my own solution, namely:

Let module-a reference module-b's own node.d.ts file so you're always referencing the same file path for Node. Problem solved, but I'm pretty sure it's a Law of Demeter violation. Also, it requires editing bower dependency files to reference the same node.d.ts file, which gets really ugly and hard to maintain.

Any ideas?