>>415
いや>>352に対する君の主張は「毎回べた書き」だろ。すり替えるなよ。

それはさておき、通常はクエリメソッドを用意しておいてそれで対応だ。
例えば Shape.type で 'rectangle' や 'circle' が取れるとか。
だからパターンマッチング自体の記述は要らんよ。（見た目は同様ではあるが)
というかそれが絶対に必要ならこれまでどうしようもなかったことになっちゃうだろ。

> ExtensionAttributeを静的クラスに付与して、コンパイルの時にそれを見てるだけ。（中略）
> そうすると、存在しないメソッドは呼び出せないので失敗することになる
だから何？コンパイラが通らないだけだろ。

話がずれているか？
上記話のすり替えをしてくる奴だから信用はしていないが。
>>405を見る限りこちらは「一般」の仮想関数だと認識して回答した。(>>413,414)
そちらは
・「拡張メソッド」の動的解決はコストが高くて、仮想関数になりえなくて、呼び出しに失敗する
ことを言っていたか？
それなら「一般メソッド」について記述した>>413,414については見解の相違なしということでいいな。

> 他の言語がShapeクラスを継承した時に必ず拡張メソッドを書いてくれることは保証できない
当たり前。というか静的にリンクするんだから、namespaceに名前がない時点でコンパイルが通らないだけ。
使う気なら自前で定義なりusingしなければならないし、無ければ使えない。
多態する気なら、例えば多重継承として実装すればいいだけ。特別なコストはかからない。
実装方式は>>414のリンクに記述してあるとおり。
拡張メソッドを多重継承として実装出来ない理由があるか？

> 利点が皆無
どこがだよ？やけくそになってないか？
拡張メソッドが多態出来ればメリットがあるのは見たら分かるだろ。
今多態出来ていないのは何か理由があるか手を抜いているか（今後対応するか）だよ。