結論
TypeScriptでSourceMapを使ってガシガシデバッグしたければRequireJS使うしか択が無いです。
AMDさん優秀。
browserifyの対抗馬としてwebpackが現れ、RequireJSオワコン説はますます強まるばかりです。私はこれまでRequireJSを使い続けていたので、乗り換えられるか調査してみました。
結果としては冒頭の通りなのですが、具体的には多段ソースマップ問題を解決できないことと、それを解決して得られるメリットが少なくデメリットすらあることにより、これ以上の調査を打ち切ることとしました。（なのでbrowserifyやwebpackの知識が十分じゃないところがあるのをご理解ください）
browserifyやwebpackはJavaScriptモジュールを変換して一つ（webpackは複数にもできる）のファイルにします。
TypeScriptからブラウザで使用するJavaScriptを作るためには、TypeScript -> JavaScript -> 一本化JavaScript の2段階のトランスパイルが必要です。。
TypeScriptからトランスパイルされたJavascriptをデバッグするにはSourceMapが必要です（まあぶっちゃけ無くてもできますが。）。この2段階のトランスパイルでは2つのSourceMap（多段SourceMapと呼ぶそうです）が得られますが、これをそのまま使うことはできません。
このことは、↓のリンクで詳しく述べられています。多段SourceMapを一つのSourceMapに変換するライブラリもあるのですが、これはwebpackなどの複数ファイルを一つにまとめるSourceMapには使用できないようでした。
多段SourceMapの対応方法とライブラリ | Web Scratch
一方RequireJSは、一つのファイルにすることもできますが、変換せずそのまま使う事もできます。TypeScriptからトランスパイルしたJavaScriptをそのままブラウザで使うので、SourceMapは何の問題なく使用できます。
ついでに、一本化に必要なビルド時間も不要です。
ところで何でbrowserifyやwebpackを使うのでしたっけ？
AMDでなくCommonJSで書けるところは、TypeScriptで書けばどちらにも出力できるわけですし、うーん。。。
まとめ
TypeScripterがRequireJSからbrowserify or webpackに移行するメリットとデメリット
メリット
- 最小構成では覚えることが少ない
- 最終的に完全に1つのJavaScriptにまとまるのでネットワーク負荷が小さい
デメリット
- SourceMapを使うのが大変、もしくは無理
- ビルドが余計に時間がかかる
なもんで、私はこれ以上調査するのをやめて、RequireJSでgulp+TypeScriptのテンプレートを書き直す事にしました。