似たような機能に対して 異なる複数のパッケージやクラスの存在は認められますか?

互いに機能が競合するパッケージ自体には問題はありません。 しかし、10のテンプレートクラス、7つものメール処理クラス、 3つのデータベースレイヤが、関数名が異なるだけで同じ動作をするといった 公害は、避けたいと思っています。

まず真実をチェックしてください。 なぜ私は新しいパッケージをコミットしたいのか、と。 "PEARで私の名前が表記される" とか、"既存クラスのAPIを理解していないから"というのは、 非常に悪い答えです。

良い理由としては、 既存の実装に特定の機能や動作・速度が欠けているということがあります。 しかし、この場合も、拡張が可能なら、そのクラスをなんとかしてみるべきです。 そうできなければ、 新しいクラスをコミットするための正当な理由となります。 ここで、"そうできなければ"の意味は、 このクラスの基礎を変更せずには必要な機能を付加できない、 ということを意味しています。

新しいクラスを書く場合は、 可能な限り既存のクラスとのAPI互換性を維持しよう努めてください。 互換性の維持ができない場合は、 互換性を維持するためのラッパクラスを作成するようにしてください。 このラッパが多くの作動時間・メモリを必要としても気にしないでください。 ラッパクラスは互換性を維持し、移行をより簡単にするためのものですから。

また、競合するクラスをコミットすることは、 PEAR開発者メーリングリスト で告知するべきです。