ヒラギノOpenTypeのProNフォントとStdNフォントは、収容グリフ数が倍以上も異なりますので、両者の差分のグリフ部分については互換性はありません。では、両者に共通するグリフ（Adobe-Japan1-3のグリフ）については互換かと言うと、これも完全に互換とは言えません。
これは、ProNとStdNで特定のUnicode符号位置に割り当てるグリフの文字幅バリエーションが異なる場合があるためで、Unicodeに依存して文字処理を行うアプリケーションでは、ProNフォントからStdNフォント（またはその逆）に書体変更すると、同じコードの文字でも文字幅が変わってしまうことがあります（例：StdNでは数学記号のΣや√にAdobe-Japan1-3内の全角グリフが割り当てられているが、ProNではAdobe-Japan1-5内のプロポーショナルグリフが割り当てられている場合）。したがって、書体変更はProNフォント同士またはStdNフォント同士で行う方が安全と言えます。
この件に関し、アプリケーション開発者の方から「StdNフォントとProNフォントの共通グリフ部分はUnicodeマッピングも共通にすべきではないか。でないと組版の互換性が維持できない」とのご意見をいただいたことがあります。しかし、StdNとProNのUnicodeマッピングを合わせると、今度はProNフォント単体でのUnicodeマッピングの一貫性が損なわれます。たとえば、数学記号のある文字はプロポーショナルグリフで、別のある文字は全角グリフで表示されるとしたら、これも不都合です。ヒラギノOpenTypeでは、各フォント単体での利便性・一貫性を優先しました。
Unicodeは原則として文字幅を規定しません。シフトJISコードでは各コードポイントに暗黙の文字幅属性がありましたが、Unicodeはそうではありません。文字幅属性も含めた情報交換や組版処理が必要なアプリケーションでは、その内部処理として、Unicodeだけでなく文字幅属性の差異（グリフの差異）を識別できるような実装が必要です。その識別に必要な情報はOpenType内部に実装されていますから（「OpenTypeレイアウトフィーチャーって何ですか？」を参照）、あとはアプリケーションの実装次第と考えます。