SetForegroundWindow

thebe.exeやeofile.exeが複数起動された場合、ThebeではWM_COPYDATA、EOFileではDDEによって、元からあるプロセスに通知を行い、元からあるプロセスが新しくスレッドを作りウィンドウを開きます。
この時、元からあるプロセスは、当然フォアグラウンドでは有り得ませんので、新しいウィンドウはSetForegroundWindowで前面に出す必要があります。
SetForegroundWindowが有効なのは、SDKによりますと、SetForegroundWindow APIを呼び出したプロセスが、以下の条件を満たす時だそうです。

The process is the foreground process.
The process was started by the foreground process.
The process received the last input event.
There is no foreground process.
The foreground process is being debugged.
The foreground is not locked (see LockSetForegroundWindow).
The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
Windows 2000/XP: No menus are active.

この制限を回避するには、AttachThreadInputを使うとよいと通常言われています。SystemParametersInfoは設定変えるので好ましくは思えませんし、何故か上手く動いてくれませんし。
で、なんで今更こんなことを、といいますと、AttachThreadInput、確かに動くのですが…これでフォアグラウンドを奪ってしまうと、ThebeやEOFileのような、シングルプロセスでGUIスレッドが複数ある作りをしていますと、Windowsが混乱してしまうようです。
前から変だなと思ってたのですがmkmさんに言及されて確信しました。
具体的には、画面上のZオーダーでは、「ThebeのSetForegroundWindowで前面に出したウィンドウ」→「たとえばthebe.exeを起動するのに使ったエクスプローラ」→「Thebeの他スレッドのウィンドウ」、となっているにもかかわらず、「ThebeのSetForegroundWindowで前面に出したウィンドウ」を閉じると、エクスプローラすっ飛ばして「Thebeの他スレッドのウィンドウ」が表に出てきてしまいます。メッセージキューとか全然別なのにも関らず、です。他にもウィンドウがフォアグラウンドを失った際混乱少々。
AttachThreadInput後にまず、現在フォアグラウンドのウィンドウをもう一度SetForegroundWindowしておくと、一見回避できているように見える、など、わけわからんです。
私の結論としては、AttachThreadInputやSystemParametersInfoといった回避策は使ってはいけない、というものです。仕様変更してまでわざわざ付け足された制限ですしね…。
ではどうすればいいかといいますと、ふたつめに起動されたプロセスは、紛れもなく以下に該当します。

The process was started by the foreground process.

この条件が無いと、新しく起動したプロセスがウィンドウを開いても前に出てこれないことになっちゃいますしね。
ですもので、元からあったプロセスが新しく開いたウィンドウのウィンドウハンドルを、新しく起動されたプロセスに通知し返して、新しく起動されたプロセスのほうでSetForegroundWindowを行えば、何の回避策も使わずに目的の動作が実現できます。
ウィンドウの所属するGUIスレッドのプロセスではなく、SetForegroundWindowを呼び出したプロセスが、判断基準なのが味噌ですね。
以上、シングルプロセス、マルチGUIスレッド、を行う時の注意事項でした。