自手副露処理のうち、再帰計算パートでポンを加味させるところまでできました。
バグが大量に出て大変だった…。

現状の成果はこんな感じです。

自手はダブ東のポンを含みにした完全一向聴。

5p、赤5p、東についてポンした場合とスルーした場合の局収支を比較し、
ポンの方が局収支が上の時は最適打を返します。

リストボックスの中身のうち、左から、
巡目、ポンしようとしている牌の番号（15が黒5p、20が赤5p、31が東）、ポンする前の手牌、最適打（-1ならスルー優位、100＋牌番号ならポン優位）と並んでいます。

このケースだと東（牌番号31）をポンするときは全部の巡目においてポンが優位（もちろんドラを使い切るため打6p）となっていますが、
5p・赤5pは役なしなので、巡目が早いうちはスルー優位（-1）となっています。
ただし、終盤は形テンのために役なしの5pもポンが有利になっています。（海底での上がりの可能性はあるので、一応最適打は打6p）

と、まぁそんな感じの出力になっています。

これがダブ東でなくてただの役牌だったら、

こんな感じで7巡目は中（牌番号37）が出てもスルー優位（-1）となっていますが、8巡目以降はポン優位という感じになってます。


ただし、再帰計算パートについては他家の現巡目以降の捨て牌とリーチや仕掛けや和了の可能性が加味されてないという点はちょっとよくないです。

特に他家和了の可能性を見込んでいないので、実際の四人麻雀だとポンするかどうかも含めた最適打が一人麻雀＋他家からの出上がり・ポンだけ考慮してるものとの乖離が出てきそうな気がします。
具体的には真の最適打は他家の上がりの可能性がある分、一人麻雀+αの最適打より早めにポンテンを取った方が有利になるとか。

全探索的なプログラムなので、他家の動向まで記憶を保存すると計算時間が発散してしまうため、どうしても他家の和了の可能性を外さざるを得ませんでした。
この最適打テーブルをシミュレーションパートにも持ち込む予定なので、真の最適打との間に乖離があるのがちょっといやーな感じですが、なにもないよりはましということで妥協しておきます。

全探索ではなくて、将棋AIみたいに盤面の評価関数とかが導入できたら、こんなびみょうな問題は出てこないとは思うのですが、それは私の技術不足ということですね。ちょこっと調べたけど評価関数の仕組みは全く理解できませんでした。
学のない者は力でごり押しするしか能がないです。

いやー、それにしてもまともに動くの作るだけで相当苦労したなー。バグだらけで苦しみました。
次はシミュレーションパート側に自手ポンの処理を書くところですな。とりあえず一番しんどいところは突破できたっぽいのでよしとしましょう。