今回はスクリプトではなくて、字形パネルの挙動が面白かったのでご報告です。
知っている方もいるかもしれませんが（そしていらっしゃったら詳細をお教え願いたい）、字形パネルの挙動が合成フォントの場合にちょっと変わった動作になるようです。
百聞は一見にしかずということで、まずは下図のようなデータを用意しました。
左側はリュウミンPr6で組んだもの。対して右側はリュウミンPr6だけど合成フォントにしたもの。見栄えは同じですが中身が違う、という状態です。
この状態から、字形パネルを使って字形を変えます。今回は末尾にある全角字形の「ｃ」を「⒞」にしようと試みました。
まずリュウミンPr6の字形パネルを参照します。
Unicode：249E
となっていますね。今度は合成フォントの方でも同様に字形パネルを参照します。
Unicode：FF43
となっています。
ではこの通り２つとも字形を変換してみると…。
合成フォントの方はU+FF43（要するに「ｃ」）のまま「異体字」としてハイライトされ、リュウミンの方はバッチリとコードポイントが変わっています。
これ、例えば正規表現スタイル等で問題になり得ます。
この例で言えばU+249Eを直接指定する正規表現（(?<=\x{249E}). 等）だけでなく、正規表現スタイルの条件を「⒞」とした場合でも、右側の例ではコードポイントが変わっていないので正規表現スタイルが適用されません。正規表現スタイルはどうやらコードポイントを元に判断しているらしいからです*1。
また、分かりやすいところではInDesignからテキストを二次利用した場合も問題になり得ます（テキスト化した際、異体字が基底文字に戻ってしまう）。
ただ、こうした字形パネルの挙動は、バグというよりは僕は仕様のような気がします。
（ちなみにCS6〜CC2017のバージョンで同様の動きを確認しました）
合成フォントかそうでないかを意識しながら字形パネルを使い分けるというのは、自分にはなかなか面倒です…。
文字（字形）を変換する際、目的とする文字の字形（CID・GID）を変えたいのか、コードポイントを変えたいのか。これを念頭に置きながら、字形パネルや検索置換を併用して作業しなきゃな…と改めて思ったのでした。
追記（2017年9月5日23:34）
やな推測だな - 実験る～む
あさうす（@assause）さんからコメントいただきました。この記事での検証はCS3ですが、「合成フォント機能は外部のCMapファイルを使って字形情報の処理をしている」というものです。
今回の件も似たような事例なのでしょう。なんとなく筋は通る気がします。
*1:過去の記事「OS間で気をつけるべき正規表現」などを参照
