Issue 1:
This is a suggestion for spec change.

Problem

Sometimes type's members could only be applicable with some restrictions of enclosing type parameter (generic type constraints).

For instance, this is use case of RxJS:

var xs: Observable<Observable<string>>;
xs.mergeAll(); // mergeAll is applicable here

var ys: Observable<string>;
ys.mergeAll(); // mergeAll is NOT applicable here

Original Rx.NET Merge method implemented as C# extension method on type IObservable<IObservable<T>>. In RxJS it's implemented as an instance method.

Current RxJS typescript definition just use unsafe trick:

export interface Observable<T> {
...
mergeAll(): T;
...
}

But it can be still unsafely called for as instance of any Observable<T>.

Possible solutions

Extension methods

Something like C# extension methods. But don't think it's useful in such cases.

declare extensions {
mergeAll<T>(this Observable<Observable<T>> source): Observable<T>;
}

BTW, extensions method could be other cool feature, which change call method (from instance-like to static-like).

Multiple interface definitions with different constraints

interface A<T> { x(): void; }
interface A<T extends B> { y(): void; }
var a: A<number>;
var b: A<B>;

a.x(); b.x(); // ok
b.y(); // ok
a.y(); // error

Member-level constraints with reference to enclosing type arguments

interface A<T> {
x(): void;
y<T extends B>(): void; // only applicable if T extends B
z<T extends B>: number; // for any property
// alternative syntax options:
<T extends B>z: number; // 1

z: number where T extends B; // 2
y(): void where T extends B;
}

I'll suggest this option. Moreover the previous solution options is special case of this one (incompatible constraints are merged on member level).

Issue 2:
TypeScript Version:

1.8.10

Inconsistencies:

1. The documentation for compiler options shows that you can set module: "none"

http://www.typescriptlang.org/docs/handbook/compiler-options.html

This suggests that there should be an option to set module: "none" in a tsconfig.json file since it's equivalent to the --module flag.

2. When editing the tsconfig.json file from within VS Code "none" is not an option for "module".

This contradicts the documentation which says "none" is a valid option.

3. If you create a new Asp.Net MVC project and add a typescript file and check the project settings you will in fact see that "None" is an option for module output and it outputs the variables as globals using IIFE pattern.

This is confusing because the if you try to set module to none from VS code the typescript compiler will actually give an error:

error TS1148: Cannot compile modules unless the '--module' flag is provided with a valid module type. Consider setting the 'module' compiler option in a 'tsconfig.json' file.

This makes you wonder how it can be possible to set modules as None when in Visual Studio.

How to compile to equivalent of module: "none"

There might be a use case where someone wants to transpile to globals like visual studio does instead of being forced to use "amd", "commonjs", or "umd" and there isn't a clear way to do that in the tsconfig.json options.

Is it true that VS code and Visual Studio are both using same compiler and should have the same features? (I know they could target different versions, but assuming they're not)

I found that if you use a combination of:

target: "es5",
module: "es2015"
...

It will show an error saying:

error TS1204: Cannot compile modules into 'es2015' when targeting 'ES5' or **lower.**

but the output looks the closes to what module: "none" used to do.

Resolution?

I would guess the easiest is to update tsconfig.json to allow module: "none" so it can be configured to behave the same as visual studio. Then it will also align with the documentation.