バグと言うより仕様的な問題でしょうが、LC_Page_Error::process() では最初に parent::process() が呼び出されているため、LC_Page_Error_Ex::process() で拡張する際保守的に「規定のメソッドで parent::process() が呼び出されている以上、親クラスの process() メソッドに何らかのコードがあった場合に備えて LC_Page_Error クラスの親クラスの process() メソッドを呼び出す」と考えるのが一般的かなと思いますが、その場合親クラスのさらに親クラスを直接呼び出すことは出来ないため、LC_Page_Error_Ex::process() から LC_Page::process() を考慮して parent::process() を呼び出すと LC_Page_Error::process() がまず実行されます。
このため LC_Page_Error::process() で拡張したエラーページを出力しようと思っても LC_Page_Error::process() のエラーページが出力されてしまうため、結果としてエラーページを重複して出力します。

つまり、LC_Page_Error::process() のプログラムをなるべく維持した状態で LC_Page_Error_Ex::process() を拡張する事が出来ない、という状態にあります。

このような混同をなくすためには LC_Page_Error::process() が親クラスの process() メソッドを呼び出さないのがベストだと思います。クラスを継承してメソッドを書き換えることで拡張とする EC-CUBE の設計思想では、本体のソースコード内で親クラスのメソッドを呼び出されてしまっては拡張のしようがなくなってしまうと思います。

下記チケットで, エラーハンドリングの修正を試みており, LC_Page_Error クラスも併わせて修正が必要だと考えています.

http://svn.ec-cube.net/open_trac/ticket/567

LC_Page_Error クラスをどう扱うか, まだ精査できていないのが現状です.
汎用的かつ拡張可能なエラーページを作成するという方針は一致していると思いますので, 参考にさせて頂きます.
ありがとうございます.

現状の設計だとエラークラスそのものがコントローラとして働いていますが、エラーそのものをコントローラから切り離さないと本質的な抽象化にはならないんじゃないでしょうか。
例えば、抽象的なエラーモデルクラスを ab_error クラスとして定義します。
エラー内容それぞれがこの ab_error を継承し、エラークラスそのものがエラーを表現しているとします。

エラーが発生したときにエラークラスの任意のメソッドを実行すると言うようなやり方だと現状の EC-CUBE の設計にはマッチしないと思うので、エラーが起きたらエラーに応じた ab_error を継承したエラークラスのインスタンスを作成する。
エラークラスは作成した際に呼び出し元クラスに定義された「エラーの出力先」に自分自身を送る。

送られた出力先はメールだったりログだったりビューだったりするわけですが、エラークラスそのものが渡されているので、エラークラスも出力先も前もって実装のルール決めておかなくても、悪い言い方すれば場当たり的な方法で拡張することが出来るので今の設計を複雑化しないでもいいかなと思いました。

そうすればビュー側で汎用的なテンプレートを持っているだけでさまざまなエラー表現に対応できますし、出力先がメールでもログでもエラークラス側がそこらへんを考慮する必要ないですし。

仮にエラーの出力先を errorHandler クラスだとしたら、以下のような実装をイメージしてみてください。

$this->errorHandler = &errorHandlerLog::getInstance(); /// シングルトン

if($result === false) $this->errorHandler->catch(new fooError(&$this));

と言うようなニュアンスですね。
エラーをメールでキャッチしたいなら errorHandlerLog を errorHandlerMail にすればいいわけですし、両方とも errorHandler を継承していればエラーのキャッチにフックした「えらー時には必ず実行させるメソッド」も他を汚す事無く実装できるんじゃないでしょうか。

ふわっとした話ですいません。ざっくりですが、興味あるならもう少しまとめた内容をお送りします。

詳細なコメントありがとうございます.
エラーハンドリングについては, 以下の前提で改善を考えています.

* 確実にレイアウトされたエラーページを表示すること
* Fatal Error でも捕捉可能なこと
* 確実にロギングすること
* PHP4 でも動作すること

EC-CUBE では, 機能によって柔軟にエラー出力先を変更する必要性が少ないことから, 本質的な抽象化よりも, より少ないコーディングで, 安全に, レイアウトされたエラーページを表示することが重要だと思っています.

ちなみに, 現在コミュニティ版にコミット済みのエラーハンドリングは, 下記を参考にしました.

http://ml.php.gr.jp/pipermail/php-users/2002-October/010916.html

引用：

最終的な実装イメージは, trigger_error でエラーを呼ぶと, 渡されたエラーコード付きのエラーメッセージに応じて, エラー処理を行ない, エラーページを表示するようにしたいと思っています.

set_error_handler にて定義するエラー関数は, オブジェクト指向の恩恵を授かることができませんが, PHP4 で Fatal を捕捉することも考えると仕方ないかなと.

コメント頂いたエラーハンドリングも, もちろん良い設計だと思いますので, 実装の参考にさせて頂きます.
ありがとうございます!