今度は手短に

http://d.hatena.ne.jp/lethevert/20050902/p3
細かいことは後回しにして、一点だけ。

インターフェースをインプリすれば、描画コンポーネントにはまりますということよりも、描画コンポーネントにべったりのデータの方が、複数言語間の変換がらくだというのは、さっぱり分からないです。普通に考えれば、逆じゃないですか？インターフェースであるということは、その実装には無関心だということですから、言語からの強制はよりゆるいと考える方が正しいと思います。だって、インターフェースを実装するかどうかは、開発者にまかされているし、後から実装することもできるんですから。

(ちょっとナナメ方向に伝わってるような気もしますが)楽とは一言も言ってません。非常に厳しいです。
内部のデータ構造そのものはお互い見せられない、メモリマネージャも共有できない、呼び出し規約はstdcallかcdecl固定で言語特有の機能も使えない、データの交換は、基本型と、データ交換用に定義された構造体に対してメモリコピーを行うことでのみ可能な世界です。
いや、マジですって。
世の中全てOOPLでも無ければ、呼び出し規約にも非常に限られた範囲でしか互換性が存在しないのです。閉口されてしまわれるかもしれませんが。COM互換interfaceだって、gccでは使えない有様ですからね…。それどころか、一般に可搬性があるとされるC言語レベルの規約ですら、16ビット×2のフィールドを持つ32ビットのCOORD構造体を、値渡しするか参照渡しするか、そんな小さなところから対応状況がまちまちなのが現実です。ちなみにWindowsAPIは値渡し前提。gccのAdaコンパイラはレコードは常に参照渡しするのでpragma書かないといけません。Delphiはレジスタサイズの構造体は値渡ししてくれます。ラッキーです。
信じられなくても、現にWindowsのツリービューコントロールはそれに耐えうる(ような)作りです。
そして、特定の言語からAPIを使っているだけですと、この制限は理不尽なものとしか映らないことでしょう…。
まあ、実際に試されない限りは、こんなので無理にでも納得していただくしかないのですが。あとデータが描画コンポーネントにべったりなのは、単にツリービューの仕様であって、リストボックスなんかはデータをコントロールに持たせずに100%オーナードローを行うためのモードがあります。
なぜツリービューにはそのためのモードが無いかといえば…MSの実装なんてものに対して推測を行うのは私の手に余りますが、親ウィンドウに問い合わせメッセージ発行しまくって、親ウィンドウが矛盾無く正しく応答や変更通知をすれば可能は可能でしょうから、やっぱ必要以上に複雑になるから以外に理由は無いような…。あり得ない応答を検出してエラーを出すだけでも頭痛そうですし。リストボックスのオーナードロー程度なら変な応答されてもせいぜい狂った描画になる程度でしょうが、構造に対する応答は、Aの次のノードを問い合わせたらBで、Bの前のノードを問い合わせたらCとか返せてしまいますからね…。

それからですね、一般的な木構造というものがありえないなら、一般的な木構造を表示する描画コンポーネントもありえないわけで、でもそんなのおかしいでしょ。木構造ってそんなに複雑ですか？

良さそうな例を思いついたので書きます。
テキストエディタ…いやこの際ビューアでもいいです。テキストビューアが取り扱うのは言ってしまえば単なる改行含みの文字列ですが、各要素が一文字を表すinterfaceで構成されたリンクリストを外部から渡されて、それをそのまま生データとして使って表示するテキストビューアコンポーネントを作れと言われたら、誰もがハァ？となると思いますよ…。表示するものは単なる文字列にも関らず、普通は内部で都合よくデータを作り替えます。そしてそのコンポーネントを使う側は、文字列を全部がさっと渡すのか、ストリームでちょっとずつ渡すのかは別にして、最終的にビューアがコピーを整形済みの状態で持つことにつっこんだりしないでしょう。(特殊用途に耐えるコンポーネントを探しているならともかく)
(良さそうな例と思いましたが、書いてみればid:pmokyさんの言ってることと同じか…しかも一点だけと言いつつ長々書いてしまった…)