v11のいくつかの機能はそんなに互換性を壊さずにv10にマージ出来ることが分かったので，マージプランを考える．
個人的には，以下の「あった方が良い」を全てマージして少し走らせた段階でv1としてリリースしたい．
この辺は開発者陣で考えがまとまったら，issueやMLに移行して，英語でもやりとりする．
配列やハッシュが使えるようになったり，Rubyのコードが使えるようになったりする．
そのまま移行すると"a"や[a]で問題が起きるので，--use-new-configのようなオプションを用意する．v10ではデフォルトfalseで，v1からはtrueにする．
移行のしやすさのためにはあった方が良い．オプション追加して処理するだけなので，多分早めに実装出来る
v10の段階でlogやemitを実装し，移行を促す．Engine.emitや$logも実装しておき，どちらからでも使えるようにしておく．
開発者はlogなどを使うためにマイナーバージョンアップと，依存するFluentdのバージョンを上げる必要があるが，主要プラグインにはパッチを投げまくればなんとかなりそう．
td-agentは勝手にバージョンがあがるので，その辺は問題無いと考える
中にmatchを持てるようにするとか，その手の機能
emit streamを実装するには必要なので，こっそり入れる．
JRubyとかでイベント駆動を抽象化するには必要だが，今のところそれほどでもない．
SocketManagerでも必要になるので，その時には入れる必要がある．
後々シグナルのハンドリング周り含め楽になる．後Workerとかのマルチコア向けの機能とかを実装出来るようになる．
Actor入れる時に一緒に入れることになる？
Bufferプラグインとかその他気になる所．