(u)pLaTeX での文字コードの扱いは、LaTeX での体系と pTeX 自身の体系の両方が絡む関係で、非常に複雑になっています。次に挙げるような複数の概念をきちんと分けて考えないと混乱してしまいます。
- LaTeX 入力エンコーディング： 文書ファイルの文字コード。inputenc のパッケージオプションで指定、値は ascii（これのみ 7 ビット; 他は 8 ビット）, latin1, koi8-r, urf8 等。無指定の場合、8 ビット欧文 LaTeX なら ascii と等価。XeLaTeX／LuaLaTeX ならば「UTF-8 直接入力」になる。
- LaTeX フォントエンコーディング： 欧文フォントの文字コード。fontenc のパッケージオプションで指定、値は OT1, OT2, LGR（7 ビット）, T1, T2A, LY1（8 ビット）等。Unicode LaTeX の場合は、「Unicode 直接」（XeLaTeX は EU1／LuaLaTeX は EU2）が可能。既定値は OT1。
- (u)pLaTeX 和文フォントエンコーディング： 和文フォントの文字コード、ハイフネーションとは無関係。普通は固定されていて、pLaTeX では JY1（横書）／JT1（縦書）、upLaTeX では JY2／JT2（同）。
- (u)pTeX 入力漢字コード： 文書ファイルの文字コード。コマンドラインオプション
-kanjiで指定。値は jis（ISO-2022-JP）、sjis（Shift_JIS）、euc（EUC-JP）、utf8（UTF-8）。既定値はビルド時に指定する。 - (u)pTeX 内部漢字コード： 和文の内部処理で用いる符号空間。コマンドラインオプション
-kanji-internalで指定。値は sjis（Shift_JIS）および euc（EUC-JP）（符号値を16 ビット整数として扱う）。upTeX ではさらに uptex（Unicode 符号値の 24 ビット整数扱い）も可能（普通はこれを指定）。既定値はビルド時に指定する。ハイフネーションとは直接には無関係。
注意事項：
- フォーマットファイルは 5. に依存する。4. には依存しない。
- 当然、文書ファイルごとにその文字コードは決まっているので、1. と 4. で矛盾する設定は無意味である。pTeX の場合 4. が utf8 以外の場合、事実上 1. は ascii しか選べない。4. が utf8 なら 1. は ascii の他に utf8（utf8x）も可能。
- ちなみに、upTeX では文書中で「日本語入力を無効化」する設定に切り替えられる。（一時的に 4. を「なし」にできると考えればよい。） 従って、「4.=utf8、1.=ascii」な日本語の文書の途中で「4.=なし、1.=latin1」なフランス語文書を \input する、という芸当が可能。
- パターンファイル（正確には、その中のパターンの記述）は 2. に相当するコードで入力しなければならない。だから、もし「直接入力」で記述するなら、通常と異なり、2. の文字コードでファイルを作ることになる。ただし、hyph-utf8 では「UTF-8 で記述されたパターンをマクロで変換する」という処理を行っていて、この場合、「パターンファイル」の文字コードは UTF-8 であるということになる。補足しておくと、パターン読込は、そもそも LaTeX のユーザレベル処理でないので inputenc とは無関係である。
- 「DVI での和文符号空間」は 5. と連動。sjis と euc の場合は jis（ISO 2022 の GL 表現）、uptex の場合は Unicode（符号値）。
- 「欧文内部処理の符号空間」は 8 ビット欧文 TeX なら 8 ビット、Unicode TeX なら Unicode（当たり前）。「DVI での欧文符号空間」はこれと同一。
これを踏まえて検討してみます。
そうしますと，今回の論点としては，とりあえずフォーマットファイル（.fmt）をうまく作成できれば，ひとまず「pTeXで完結する分」については何とか行けるということになりますでしょうか。
そうです。そのフォーマットを使うのは「pTeX ユーザ」であって、非英語欧文文字を安全に扱うためのノウハウを持っていると想定できますので（「我々には美文書4版付録Jがある」）。
そうすると，少なくともjis（iso-2022-jp）, euc，sjisの三者では現時点ですでにフォーマットファイルの共有は出来ているということなのでしょうか。
フォーマットファイルは入力漢字コード（4.; utf8 も含む）に依らずに共通のものが使えます。和文は内部漢字コード（5.)に変換されて処理されているからです。逆に言うと、5. が違うものの間では共有できません（無論 1 つのシステムで複数の 5. に対応させる必要性は全くない）。アスキー社のオリジナルの pTeX の場合、4. が euc／sjis なら 5. も同じと決め打ちしていたので（先の理由により）共有は不可能でした。
ハイフネーションの側から見ると，euc，sjis＋ラテン，ギリシャ，キリル文字の7ビットコード（具体的にはアクセントなどをlatin transliterationで記す）についてはこれで正常に処理出来ることになります。
（iso8ビットのソースについては入力段階で引っかかるので処理は出来ませんが）
これはその通りです。（つまり 1. が ascii ならば OK です。）
問題はutf-8で，こちらは分綴処理が異なる（アクセントや合字の扱い～文字コード上で～が異なっている）はずなので，本来ならばutf-8専用のフォーマットファイルが必要です。hyph-utf8開発チームのテーマがまさにこれで，XeTeXやLuaTeXのようなutf-8デフォルトのパッケージと従来のLaTeXシステムを共存できるように（一括でフォーマットファイルが作成できるように）文字コードを自動判別するというというものです。
フォーマットファイル中のパターン情報が依存するのは 1. ではなく 2.（フォントエンコーディング；これには“utf-8”という指定はない）です。8 ビット欧文 LaTeX で UTF-8 入力を用いた（1. に utf8 を指定）としても、2. は不変なので別のパターンを用意する必要はありません。結果的に、1 つのエンジンがパターン情報の異なる複数のフォーマットを持つ必要は生じていないのです。
補足：ところで 1 つの言語について複数のフォントエンコーディング（2.）を使い分けたいということはありえます。例えば、ロシア語では、ASCII 翻字入力ならば 2. は必然的に OT2 ですが、UTF-8 入力（1. が utf8）の場合は 2. は T2A にしたい所です。だからパターンが 1 つしか選べないというのは実は不便だったりします。両方を登録すること自体は可能なのですが、残念ながら、現在の Babel にはパターンを「切り替えて使う」機能がありません。
同じことはpTeXとpTeX-Unicodeの間にも当てはまると思います。現在のptexencでは，ラテン文字についてはutf-8で入力可能なので，この範囲でutf-8用フォーマットファイルの恩恵を受けることが出来ることになるでしょうか。結局フォーマットファイルは従来のJIS＋7ビット用とutf-8用の二つが必要になると思われます（iso8ビットについては処理が出来ないので考慮から外れます）。この処理が出来ればOKということになりますでしょうか。
以上のことを考え合わせると、これは正しくないことが解ると思います。(u)pTeX は欧文については 8 ビットなので、4. を utf8 にしても、さらに 1. を utf8 にしても、また upTeX だとして 5. を uptex（Unicode）にしても、2. は結局変わらないので、パターンを変える必要はないわけです。