Isn't the first rule of speed optimization the one that the output of an optimized program must not differ from the output of the unoptimized one, given the same input? Is it not possible to achieve those performance improvements in other ways? Like for example,
introducing aggressive caching of compilation data?

I really like TypeScript, but I have serious doubts about the direction where its headed now. Really hoping its just some sort of a temporary pre-1.0 phase where you remove things you're not sure you'd like to support forever...

In large part, the design changes in the language since 0.9.1 have focused on:

Catching errors

Not getting in the user's way

Typing more patterns in JavaScript (while still doing #2)

Simplifying the type system so that errors are easier to reason about

There were some changes that did have an impact on compile speed mostly because we opted for a simpler, easier-to-understand design.

To your specific points:

The thread in
https://typescript.codeplex.com/workitem/1647 is around the visibility of types when using external modules. For separate compilation scenarios where you output a .d.ts file, you need to be able to name the types of symbols and functions. You can import
modules and use only the type information, and the result won't have any impact on the .js file (basically, we never write out a require statement if you only use the module for type information). The issue is really around the visibility of the type names
and if the compiler has enough available to express them.

The thread on
https://typescript.codeplex.com/discussions/471751 touches on the switch from using 'any' to something that would help catch more errors in code where the user doesn't explicitly annotate ambiguous inference situations. We had been just using 'any', which
meant the user wouldn't get any help. Making this change did help projects catch these ambiguous situations and fix them.

Neither of these really is about compiler speed, but rather about helping programmers catch bugs and annotate their programs as clearly as possible. We're trying to, and I like your phrase, "optimize for programmer happiness" by striking a balance
for a type system that easier to understand while still strong enough to catch issues.