コードのコンシューマーは、実際には using ステートメントを持つ必要がないことに注意してください。それらは生活を楽にするためにあるので、ソース全体に antlr.collections.Foo と antlr.collections.Bar を入力する必要はありません。
より大きな「影響」(実際に深刻な影響がある場合) は、コードの消費者が antlr.collections が定義されているアセンブリへのハード参照を必要とすることです。
ただし、それが事前に文書化されている場合、正直なところ、それほど大きな問題ではないと思います. これは、生成された DAL アセンブリと元の SubSonic アセンブリの両方への参照を必要とする、SubSonic で生成された DAL のコンシューマーと同じです。(そして、おそらくステートメントも使用します。)
依存関係は、それらが何であるかです。クラスが名前空間に分割されるのには理由があります。これは主に、組織化と名前の競合を減らすためです。あなたが言及した名前空間にどのクラスがあるかわからないので、あなたのシナリオで実際にそのような競合がどの程度発生する可能性があるかわかりません...しかし、クラスをある名前空間から別の名前空間に移動しようとするか、そのようなものが必要であるという事実を隠そうとしますそこから空のクラスを派生させることは、おそらく最良のアイデアではありません。別の参照と using ステートメントを使用しても、クラスのコンシューマーが殺されることはありません。