木下です。

MySQL日本語要望オフお疲れさまでした。
お蔭様で帰りの電車がなくなるくらい有意義な時間を過ごさせていただきました＾＾；

cp51932についての私見を述べさせてください。

ご指摘の記事の中に出てくる
http://www.rikai.com/library/kanjitables/kanji_codes.euc.shtml
をざっと見たところ、eucJP-openとの違いは、SJISでの「NEC選定IBM拡張文字」(ED40〜EDFC)を
そのままの句点コードに対応するEUCでの領域 (F9A1〜FCFE) に割り当てているみたいです。
この領域は eucJP-open ではSJISでの 外字領域を保持する部分の一部です。
cp51932への対応は少なくともEUCで外字領域を保持することと二者択一になりそうですね。
ただ、SJISで直接格納できないPostgreSQLと違い、MySQLのcp932では外字領域が考慮されているので、
MySQLではEUCで外字を格納するケースのほうが稀かも知れません。

またもうひとつ分かれ道がありまして、「NEC特殊文字」は「JIS X 0208(EUCでは２バイト文字)」と、
「NEC選定IBM拡張文字、IBM拡張文字」は「JIS X 0212(EUCでは３バイト文字)」と
それぞれ重複する文字があり、MySQLでの cp932→eucjpms の変換では JISの文字がある場合は
JISの文字として変換されます。
（※PostgreSQLではNEC特殊文字だけはそのままの句点コードで変換されるようですが。)
このポリシーのまま対応すればどちらにせよ、ご指摘の問題の発端となっている文字は
JIS X 0212(補助漢字)に変換され、EUCでは"8F"で始まる３バイト文字に変換されます。

しかし個人的にはJISの文字に揃える変換の方が、検索などの実用上望ましいと思います。

ご指摘の問題の原因は、マッピングの差異も確かにあるのですが
寧ろ、「JIS X 0212」までで規定されているEUCエンコーディングでの３バイト文字を
表示できないIEの不具合なのではないでしょうか？
FireFox(WinXP版)では"FAE3"も"8fc7cb"も両方表示できるので(cp51932が考慮されていますね・・)、
ページ上から入力を行おうとしない限りは文字化けは起こらないと思います。

ちなみに、私がベンダ固有文字の変換について調査した範囲では
簡単に書くと、
PostgreSQL:	eucJP-open
MySQL:		eucJP-open(eucjpms) or 対応なし(ujis)
Oracle:		JIS X 0212までのJISに含まれる文字のみ変換
となっております。
これらのRDBMSでは、cp51932は意識されていません。

以上、長文で失礼しました。
分かりづらくてすみません。

-- 
木下  靖文
e-mail: kinoshita.yasufumi@xxxxxxxxxx