java, c# 追加失敗時の処理
こんにちは。c#初心者兼、「java始めました」です。
プロパティ（文法）がなくて、わざわざget/setと括弧をつけないといけないし、finalつけないと勝手にオーバーライドされるかもだし、演算子定義できないし、ジェネリックは弱いし、…etcの代わりに、staticやfinalでやたらとインライン展開されて、凄いと感心している最中です。
さて、クラスのメソッド設計なのですが、クラスやメソッドのあり方についての質問です。
キーが一意にノード（値）と結びついているコレクションクラスを作成中なのですが、ちょっと問題発生です。
Setや、javaで言うMap、c#で言うDictionaryクラスには追加メソッド（addとかput）がありますが、その戻り値はvoid型（javaなら値の型もあるかな）が多いと思います。
そのため、キーが重複した際の処理はjavaは上書き、c#は例外（インデクサは上書き）となっており、一長一短です。
どちらの方式でも使用側が存在するかどうかのチェックを先に行えばよいのですが、使用側のコードが増えるし、どうせ今から作るクラスならもっと便利なものを作ろうという予定です。
用意する予定の追加関連のメソッドは、
(1)（c#風）追加を試み、成功時には生成されたノードを、キー重複の場合には例外をスローするメソッドadd(K key, V value) / Add(TKey key, TValue)、
(2)追加を試み、成功時には生成されたノードを、キー重複の場合にはnullを返すメソッドtryAdd(K key, V value) / TryAdd(TKey key, TValue)、
(3)（java風）追加を試み、キーが存在しない場合にはそのまま追加し、重複の場合は上書きし、どちらの場合も最後に生成されたノードを返すset(K key, V value) / Set(TKey key, TValue)、
(4)追加を試み、成功時には生成されたノードを、キー重複の場合には既存のノードを返すメソッドtryGetAdd(K key, V value) / TryGetAdd(TKey key, TValue)、
と、ここまでを振り返って思ったことですが、(2)のtryAdd/TryAddが(1)の（使用者側から見て）ほとんど上位互換になっているということです。
機能が酷似し、チェックの方法が異なるだけで、非常に特殊な場合では(2)はチェックなしでも安全に利用可能なので(1)の利用価値が希薄です（(1)にはチェックを半強制させるという安全面でのメリットがないわけではないですが…）。
もちろん、addという分かりやすいメソッドがあったほうが安心する利用者はいると思いますし、インターフェイスの視点からもあった方がいいとおもいます。
それでもデフォルトで、一番使われそうなadd/Addメソッドがあまり使われないようなクラスというのはいかがなものなのでしょうか？
大丈夫ならそれでいいのですが、不自然、メソッドがややこしすぎる、などはないでしょうか？
どなたでも気づいたことがあればご指摘ください。
お礼
情報ありがとうございます。