-include仕様

Seasar2を実際に案件に使ってみて、便利につかってしっかり「稼いで」ます。すでにリリースしたプロジェクトもありますし、今も2本平行で採用プロジェクトが動いてます。が、やはり今のincludeは直感的ではないと日増しに思うようになりました。下方検索でなく上方にコンポーネントが移動してルートコンテナで集積される仕組みと自動インジェクションが相乗して実際にもいくつか小さな問題が発生しました。A include B、B include C、A include Dのときに、直感的にA-B-Cのコンテナの間での依存性解決するだけならわかり易いのですが、DのコンポーネントがB、Cのコンポーネントプロパティに自動でインジェクションされるので予測しない動きでハマルことがありました。また、Dのコンポーネントのために、A-B-CのところでTooManyになったりするのも、エラー要因はエラーメッセージ等からすぐ判別できますし、回避の方法もいくらでもあるのですが、いくらかストレスに感じます。
Kijimunaのincludeも実装中途ですが、この機能をカバーするために実装がシンプルじゃなくなっちゃうのですよ。ひがさんとちょっと話したときには「ルートを決め打てばいい」という話だったけど、決め打つにはそのためのGUIを作ったうえで、ユーザーに指定させなければならない。プロジェクトにNatureを設定（「is S2 project」チェックボックスをチェックする）するだけでビルドに入る今の仕組みに、ユーザー設定事項が少なくともワンステップ以上入る。
includeおよび名前空間仕様を再検討しませんか？私もプラグインでサポートするにあたって中途半端なことしたくないので、一度整理したいです。デザインタイムはランタイム時と違ってファイルを削ったり追加したりするし、エディットします。コンテナの影響範囲が広いと、再処理時のビルド範囲を局所化することができずに、毎度フルパースの仕組みにせざるを得ません。そうするとデザインタイムとして致命的なことにIDEの反応が重くなっちゃう。じゃあIDEはいらないかというと、すでに検討終わってる自動インジェクション状況の表示を行う機能も含めて、絶対あったほうがうれしいと思うのですね。
くどい話ですが、コンポーネントの検索をルートに見に行かず、下方に検索するだけにしたいです。もっと言うとincludeした当事者間だけの関係にしたいぐらい。ネームスペースで引くときは各コンテナ宣言型（これもちょっと異議があってinclude命名型のほうが名前が重ならなくていいですが、とりあえず置いておきます）なのでつながってさえいればイトコだろうとハトコだろうと見に行ってもいいけど。。。まあ、こっちも限定したいです。（私はまったく望んではいませんが）自動インジェクション機能を全廃するよりは穏当かと思います。