forum:1748 を読み返してみて思ったのですが
「pLaTeX で CJK パッケージを知ってか知らずにか読み込んで意味不明な結果が出る」
というケースは割とありうるのかなと思います。（私も最初「ルビが小書きにならない」と
CJK.sty の \selectfont との関連性に、最初はまったく気づきませんでした）
forum:1858 もよくわからずに CJK パッケージを使ってしまった例だと思います。
そこでなのですが、逆に「pLaTeX で CJK パッケージを読み込むことで助かる例」というのは
あるのでしょうか？ もしないのであれば、pLaTeX / upLaTeX コミュニティ版では最初から
CJK パッケージを使えないようにしてしまうという方法も考えられますが、いかがでしょうか？
逆に「pLaTeX で CJK パッケージを読み込むことで助かる例」
CJKパッケージが何者なのかを知っていて、かつ明確な意思を持って pLaTeX で CJK パッケージを使おうと試みた、という事例で自分が知っているのはコレだけですね。
（もちろん、Cloud LaTeX が“何か裏で細工をしている”のでない限り、この試みは失敗するはず。）
pLaTeX / upLaTeX コミュニティ版では最初から CJK パッケージを使えないようにしてしまう
現状で“単に CJK を読み込むだけ”だと \selectfont が潰れてしまって使い物にならないはず。だとすると、(u)pLaTeX + CJK の組合せを「実用」している人が、もし仮にいたとしたら、その人は \selectfont を整合させるためのコードを書いているはずです。（既存のコードは見たことがない。）
ということは、CJK パッケージをブロックする仕組みを入れたとしても、そういう人は恐らくその仕組みを簡単に回避できるだろうから対して困らない、と考えられるのですがどうでしょう……。
> あるフォーマットが特定のパッケージを使えないようにしている，という例ってあるんでしょうか？
私が知っている例は LaTeX2e が autofss1.sty を読めなくしていることくらいです。
autofss1.sty は NFSS1 の時代のパッケージでしょうから、NFSS2 を壊します（たぶん）。
ltfssbas.dtx 冒頭で「読み込み済み扱い」されています。
\expandafter\let\csname ver@autofss1.sty\endcsname\fmtversion
これはたぶん LaTeX チームが作った LaTeX というフォーマットが、過去の自分たちが作った
パッケージを読み込み禁止にしているのですから、今回の CJK と pLaTeX とは少し異なる
かもしれません。
追記：いま latex.ltx をもっと読んでみると autotabg.sty / autopict.sty / autoout1.sty も同様でした。
私が知っている例は LaTeX2e が autofss1.sty を読めなくしていることくらいです。
autofss1.sty は NFSS1 の時代のパッケージでしょうから、NFSS2 を壊します（たぶん）。
ltfssbas.dtx 冒頭で「読み込み済み扱い」されています。
\expandafter\let\csname ver@autofss1.sty\endcsname\fmtversion
これはたぶん LaTeX チームが作った LaTeX というフォーマットが、過去の自分たちが作った
パッケージを読み込み禁止にしているのですから、今回の CJK と pLaTeX とは少し異なる
かもしれません。
追記：いま latex.ltx をもっと読んでみると autotabg.sty / autopict.sty / autoout1.sty も同様でした。
> 特定のパッケージを名指ししてナントカ、という処理は気持ち悪いかも……。
私もそう思います．Warning ぐらいなら許容かも．
「\selectfont が壊れていないか」は他のパッケージ読み込みでもあるかもしれないので，検査するのはありかもしれないです．
一方で，どこまでコミュニティ版 pLaTeX での改変を許容するのかも議論しどころです．
アクセントの変更時のように，改変は即エンバグにつながりますので．
LuaTeX-ja は，LuaTeX 本体もベータなんだからこれもベータなんだ，と言っておけばよいですが，
pLaTeX は利用者が多いので，バグの影響も大きいです．
stable/unstable の区分があればよいのですが……．分けても unstable を試す人が少なくてあんまり意味ないのかな．
私もそう思います．Warning ぐらいなら許容かも．
「\selectfont が壊れていないか」は他のパッケージ読み込みでもあるかもしれないので，検査するのはありかもしれないです．
一方で，どこまでコミュニティ版 pLaTeX での改変を許容するのかも議論しどころです．
アクセントの変更時のように，改変は即エンバグにつながりますので．
LuaTeX-ja は，LuaTeX 本体もベータなんだからこれもベータなんだ，と言っておけばよいですが，
pLaTeX は利用者が多いので，バグの影響も大きいです．
stable/unstable の区分があればよいのですが……．分けても unstable を試す人が少なくてあんまり意味ないのかな．
> どこまでコミュニティ版 pLaTeX での改変を許容するのか
これは私も一度議論しておきたいと思っていました。それも参加者の多い場で。
それが本トピックを github でなく forum に立てた理由でもあり、forum:1934 で周知を
試みた理由でもありました。
unstable を github と別に作ることは、github を見てくださる方にとっては意味がない
と思っています。それでも、stable にエンバグを入れないようにするのは難しいです。
これは私も一度議論しておきたいと思っていました。それも参加者の多い場で。
それが本トピックを github でなく forum に立てた理由でもあり、forum:1934 で周知を
試みた理由でもありました。
unstable を github と別に作ることは、github を見てくださる方にとっては意味がない
と思っています。それでも、stable にエンバグを入れないようにするのは難しいです。
fixltx2e.sty を思い出して、またふとした思いつきですが。
exppl2e.sty（名前は適当）のような「experimental なコードを入れたパッケージ」を作って
pLaTeX といっしょに TeX Live で配布する、という案はいかがでしょう？
かつての plpatch.ltx の仕組み (quick fix) は結局フォーマットを regenerate しないといけなかった
わけですが、そうではなく sty なら experimental / stable を手軽に切り替えていただけるでしょう。
experimental で実績が出てから本体に取り込むことで、エンバグの可能性は小さくなると思います。
exppl2e.sty（名前は適当）のような「experimental なコードを入れたパッケージ」を作って
pLaTeX といっしょに TeX Live で配布する、という案はいかがでしょう？
かつての plpatch.ltx の仕組み (quick fix) は結局フォーマットを regenerate しないといけなかった
わけですが、そうではなく sty なら experimental / stable を手軽に切り替えていただけるでしょう。
experimental で実績が出てから本体に取り込むことで、エンバグの可能性は小さくなると思います。
> 「LaTeX カーネルと同じ基準にする」
同意します。そして「LaTeX カーネルの基準」を抽出するために
> LaTeX カーネルがこれまで何を修正してきたか
が必要なわけですね。
pLaTeX を今後変更するとして、修正（バグフィックス）と改変（仕様変更）があると
思いますので、区別した基準が必要でしょうか。
LaTeX カーネルの変更のうち、は 2014 年までは両者が割と区別されていて
・latex.ltx に直接入ってきたコード変更が「修正」
・fixltx2e.sty に入ってきたコード変更が「改変」
なのでしょうけど、2015 年以降は一緒くたになっていますし若干難しそうです。
latex-team list は closed のためアーカイブは（少なくとも私には）見えませんから、
時には source2e や ltnews から少々深読みしないといけないようです。
同意します。そして「LaTeX カーネルの基準」を抽出するために
> LaTeX カーネルがこれまで何を修正してきたか
が必要なわけですね。
pLaTeX を今後変更するとして、修正（バグフィックス）と改変（仕様変更）があると
思いますので、区別した基準が必要でしょうか。
LaTeX カーネルの変更のうち、は 2014 年までは両者が割と区別されていて
・latex.ltx に直接入ってきたコード変更が「修正」
・fixltx2e.sty に入ってきたコード変更が「改変」
なのでしょうけど、2015 年以降は一緒くたになっていますし若干難しそうです。
latex-team list は closed のためアーカイブは（少なくとも私には）見えませんから、
時には source2e や ltnews から少々深読みしないといけないようです。
> 「\selectfont が壊れていないか」は他のパッケージ読み込みでもあるかもしれないので，検査するのはありかもしれないです
ありかなぁと思わなくもないですが，何故\selectfontだけ，という気もしますね……．
（個人的にはCJKがplatexを拒否するのが自然な気がするのですが，どうなんでしょう？）
-----
> pLaTeX は利用者が多いので，バグの影響も大きいです．
おっしゃる通りかと．バグに当たって，例えばコンパイルができなくなったりするとかなり致命的に困る（それこそ今日の仕事が全くできない！）とかいう人もたくさんいるんじゃないかと思います（例えば自分のことですが……）．ので，もっとバグを出さない努力をした方がよいかなと思います．定番（かつ動けば有効な）方法は
> stable/unstable の区分があればよいのですが……．
だと思いますが．
> 分けても unstable を試す人が少なくてあんまり意味ないのかな．
例えば「五人くらいのplatexをそれなりに常用している人数ヶ月試す」くらいでわりと洗い出されたりしませかね？このくらいならばありそうな話かなぁと．unstableを試すのが気楽にできるとよいですね．
（例えばマクロのみで構成されているLuaTeX-jaの場合は，自分のtexmfに放り込んでおけばそれだけで試せるので個人的には割と気楽に試せます．もし致命的に困ってもいったんそれを消してしまえばシステムのLuaTeX-jaになりますし．）
ありかなぁと思わなくもないですが，何故\selectfontだけ，という気もしますね……．
（個人的にはCJKがplatexを拒否するのが自然な気がするのですが，どうなんでしょう？）
-----
> pLaTeX は利用者が多いので，バグの影響も大きいです．
おっしゃる通りかと．バグに当たって，例えばコンパイルができなくなったりするとかなり致命的に困る（それこそ今日の仕事が全くできない！）とかいう人もたくさんいるんじゃないかと思います（例えば自分のことですが……）．ので，もっとバグを出さない努力をした方がよいかなと思います．定番（かつ動けば有効な）方法は
> stable/unstable の区分があればよいのですが……．
だと思いますが．
> 分けても unstable を試す人が少なくてあんまり意味ないのかな．
例えば「五人くらいのplatexをそれなりに常用している人数ヶ月試す」くらいでわりと洗い出されたりしませかね？このくらいならばありそうな話かなぁと．unstableを試すのが気楽にできるとよいですね．
（例えばマクロのみで構成されているLuaTeX-jaの場合は，自分のtexmfに放り込んでおけばそれだけで試せるので個人的には割と気楽に試せます．もし致命的に困ってもいったんそれを消してしまえばシステムのLuaTeX-jaになりますし．）
> （個人的にはCJKがplatexを拒否するのが自然な気がするのですが，どうなんでしょう？）
それだと CJK.sty の著者に依頼することになりますが、どうかすると
「私たちの pLaTeX を壊すので迷惑だから、CJK.sty を pLaTeX で使えないようにしてくれ」
とでも言っているかのように思われないか心配です。
（極端に最悪なケースを想像しただけですので、さすがにそこまではないと思いますが）
そこまでひどくなくても、あらゆるパッケージの著者に「pLaTeX のことを考慮してくれ」
と依頼するのは、非現実的だと考えています。
> 「\selectfont が壊れていないか」は他のパッケージ読み込みでもあるかもしれないので，
> 検査するのはありかもしれないです．
はそれを加味してのことだとも思います。
> 例えば「五人くらいのplatexをそれなりに常用している人数ヶ月試す」くらいで
> わりと洗い出されたりしませかね？
「critical な修正にはいちいち時間をかけない」を留保すれば、機能しそうです。
> unstableを試すのが気楽にできると
これは私案をすでに出しました。もっといい案を歓迎です。
それだと CJK.sty の著者に依頼することになりますが、どうかすると
「私たちの pLaTeX を壊すので迷惑だから、CJK.sty を pLaTeX で使えないようにしてくれ」
とでも言っているかのように思われないか心配です。
（極端に最悪なケースを想像しただけですので、さすがにそこまではないと思いますが）
そこまでひどくなくても、あらゆるパッケージの著者に「pLaTeX のことを考慮してくれ」
と依頼するのは、非現実的だと考えています。
> 「\selectfont が壊れていないか」は他のパッケージ読み込みでもあるかもしれないので，
> 検査するのはありかもしれないです．
はそれを加味してのことだとも思います。
> 例えば「五人くらいのplatexをそれなりに常用している人数ヶ月試す」くらいで
> わりと洗い出されたりしませかね？
「critical な修正にはいちいち時間をかけない」を留保すれば、機能しそうです。
> unstableを試すのが気楽にできると
これは私案をすでに出しました。もっといい案を歓迎です。
確かに LuaTeX-ja は ~/texmf/tex/luatex/ に入れておいてあとは日々 git pull しておけば
自動的に普段の作業でテストできるので，そんな感覚にできるとよいですね．
platex で現状それができないのはフォーマット作成が必要だからなので，
.sty で unstable コードを動かせるようにするのはありだと思います．
あとは実際にこれで使ってくれる人がどれだけいるかの問題です．
申し訳ないことに，私は普段の作業では platex は使っていないので……．
（たまに使うことはあるのですが．）
--
CJK.sty についてはアセトアミノフェンさんの意見と私も同じで，
LaTeX しか想定していないパッケージ作者に日本ローカルの pLaTeX を考慮せよと
いうのは無理があると思っています．
自動的に普段の作業でテストできるので，そんな感覚にできるとよいですね．
platex で現状それができないのはフォーマット作成が必要だからなので，
.sty で unstable コードを動かせるようにするのはありだと思います．
あとは実際にこれで使ってくれる人がどれだけいるかの問題です．
申し訳ないことに，私は普段の作業では platex は使っていないので……．
（たまに使うことはあるのですが．）
--
CJK.sty についてはアセトアミノフェンさんの意見と私も同じで，
LaTeX しか想定していないパッケージ作者に日本ローカルの pLaTeX を考慮せよと
いうのは無理があると思っています．
> .sty で unstable コードを動かせるようにするのはありだと思います．
> あとは実際にこれで使ってくれる人がどれだけいるかの問題です．
現状は（意図したかどうか・望ましいかどうかはさておき）
・どんどん pLaTeX を変更する
・エンバグなり不都合が生じたら platexrelease のエミュレートで回避
なのですよね。確かにこれは一定の成果をみている気もします。
「数人の有志で数ヶ月みる」より相当早いペースでレポートが
飛んできていますし、quick fix も提供しているわけですから。
ただ、自分で実装しておきながら変な話ですが、platexrelease が
活躍してしまっているのは嬉しくないです。いままでの回避策も全部
「2016/03/31 でエミュレートしろ」なわけで、つまりコミュニティ版の
「脚註番号前後のアキ問題」も込みでキャンセルしています。
正直な話、コミュニティ版の恩恵を受けることができない状態です。
これよりは、たとえテストしてくださる方が少なくても sty で実験する
ほうが安全ではないかと思ってしまいますが、どうなのでしょう。
> あとは実際にこれで使ってくれる人がどれだけいるかの問題です．
現状は（意図したかどうか・望ましいかどうかはさておき）
・どんどん pLaTeX を変更する
・エンバグなり不都合が生じたら platexrelease のエミュレートで回避
なのですよね。確かにこれは一定の成果をみている気もします。
「数人の有志で数ヶ月みる」より相当早いペースでレポートが
飛んできていますし、quick fix も提供しているわけですから。
ただ、自分で実装しておきながら変な話ですが、platexrelease が
活躍してしまっているのは嬉しくないです。いままでの回避策も全部
「2016/03/31 でエミュレートしろ」なわけで、つまりコミュニティ版の
「脚註番号前後のアキ問題」も込みでキャンセルしています。
正直な話、コミュニティ版の恩恵を受けることができない状態です。
これよりは、たとえテストしてくださる方が少なくても sty で実験する
ほうが安全ではないかと思ってしまいますが、どうなのでしょう。
そもそもバグ出さないという観点だと欲しいのはstable/unstableに加えてtestingでした．
> .sty で unstable コードを動かせるようにするのはありだと思います．
バグ出さないという観点では，「リリースされるものとまんま同じ物が試せる」べきな気がしてあまりありな気がしないです．最後の改変でバグるかもしれないし．（もちろん機械的な変換で問題が起こらないことが証明されるのならばいいのですが．）
> platex で現状それができないのはフォーマット作成が必要だからなので，
# だんだんフォーマット作成すればいいだけじゃねって気がしてきた……
> .sty で unstable コードを動かせるようにするのはありだと思います．
バグ出さないという観点では，「リリースされるものとまんま同じ物が試せる」べきな気がしてあまりありな気がしないです．最後の改変でバグるかもしれないし．（もちろん機械的な変換で問題が起こらないことが証明されるのならばいいのですが．）
> platex で現状それができないのはフォーマット作成が必要だからなので，
# だんだんフォーマット作成すればいいだけじゃねって気がしてきた……
> そもそもバグ出さないという観点だと欲しいのは
> stable/unstableに加えてtestingでした．
LuaTeX-ja と比較されていますが、いまの pLaTeX は
「フォーマット作成が必要」
だけでなく
「複数の dtx から plcore.ltx がストリップされる」
というのも難点です。他方 LuaTeX-ja は sty やら lua の直書きで
すから楽です。おそらく stable/unstable/testing は git branch の違い
を想定されているのだと思いますが、plcore.dtx だけでも大量の
コードですから、git merge は注意しないと conflict してしまいます。
通常は testing が最上流で unstable がその次…となるでしょうが、
新たに判明したエンバグを急遽修正したい場合は全ブランチに同等の
変更を入れます。即 conflict でしょう。\CheckSum も手で書きかえ
ないと merge できません。なのでブランチをあんまり増やすのも
考えものです。 以上、実際に色々 commit してみた個人的な実感です。
# 「もっとバグを出さない努力をした方がよいかなと思います．」
# それは当然ですよ。
結局、pLaTeX の dtx を根本的に細かく分割でもして、ストリップ
される ltx も細かく分割してしまえば万事解決でしょうか。
-----
本家 LaTeX はというと、svn で dtx だけを管理しています。
だから、実際にテストするには svn co のあと build.lua を走らせて
latex.ltx を自分のところでストリップします。その方法なら若干 conflict
しにくくなるかもしれませんが、build の手間はかかります。
> stable/unstableに加えてtestingでした．
LuaTeX-ja と比較されていますが、いまの pLaTeX は
「フォーマット作成が必要」
だけでなく
「複数の dtx から plcore.ltx がストリップされる」
というのも難点です。他方 LuaTeX-ja は sty やら lua の直書きで
すから楽です。おそらく stable/unstable/testing は git branch の違い
を想定されているのだと思いますが、plcore.dtx だけでも大量の
コードですから、git merge は注意しないと conflict してしまいます。
通常は testing が最上流で unstable がその次…となるでしょうが、
新たに判明したエンバグを急遽修正したい場合は全ブランチに同等の
変更を入れます。即 conflict でしょう。\CheckSum も手で書きかえ
ないと merge できません。なのでブランチをあんまり増やすのも
考えものです。 以上、実際に色々 commit してみた個人的な実感です。
# 「もっとバグを出さない努力をした方がよいかなと思います．」
# それは当然ですよ。
結局、pLaTeX の dtx を根本的に細かく分割でもして、ストリップ
される ltx も細かく分割してしまえば万事解決でしょうか。
-----
本家 LaTeX はというと、svn で dtx だけを管理しています。
だから、実際にテストするには svn co のあと build.lua を走らせて
latex.ltx を自分のところでストリップします。その方法なら若干 conflict
しにくくなるかもしれませんが、build の手間はかかります。
> > .sty で unstable コードを動かせるようにするのはありだと思います．
> バグ出さないという観点では，「リリースされるものとまんま
> 同じ物が試せる」べきな気がしてあまりありな気がしないです．
Issue 9 の議論をややこしくしてしまいましたが、pLaTeX に限っては
「リリースされるものとまんま同じ物が試せる」
を文字通り実現することは、私の貧弱な発想力では
「正味のテスト回数を増やす」
ことと両立しないです。
まんま同じものが試せるということは
・TeX Live には stable だけを入れる
・GitHub には stable に加えて unstable branch を作る
しかないと思います。つまり、試してくださる方に対して
「GitHub から unstable を取ってきて、フォーマットを作る」
を要求することになります。この手間を取ってくださる方が、以前仰っていた
> 「それなりに常用している人数ヶ月試す」くらいで
> わりと洗い出されたりしませかね？
に対応すると思うのですが、多く見積もって20人程度でしょう。
pLaTeX ほど広く使われているものに限っていえば
「全 pLaTeX 利用者数」に占める「20人」は少なすぎるかと。
特に forum:1958 の「アクセント文字を含む PDF しおり」なんかは、
その20人の中でしおり常用者がいなければ盲点でしょう。
「.sty で unstable コードを動かせるようにする」
という案は、sty を TeX Live にも含めてしまうことを視野に入れています。
GitHub を取りにくる手間も、フォーマットを作る手間も要りません。
そのほうが正味のテスト回数は増えると思います。
# この帰結に「どうせ sty であって “まんま同じもの” ではない偽物だから、
# 試してもムダだ」と思われない、という仮定が入っていることは認めます。
いま Issue 9 で模索しているのは、本格的にテストしてくださる方（20人 ± α）
のための「sty をいちいち手動で \RequirePackage せず済むような自動化法」
です。
> 最後の改変でバグるかもしれないし．
は、「最後の改変一発」と「頻繁な改変」のどちらがバグりそうかと考える
と、一概にいえないと思います。
長々書きましたが、要は明確な代案が欲しいです。git にコミットする人に
とってもテストする人にとっても動きやすい代案を。
> バグ出さないという観点では，「リリースされるものとまんま
> 同じ物が試せる」べきな気がしてあまりありな気がしないです．
Issue 9 の議論をややこしくしてしまいましたが、pLaTeX に限っては
「リリースされるものとまんま同じ物が試せる」
を文字通り実現することは、私の貧弱な発想力では
「正味のテスト回数を増やす」
ことと両立しないです。
まんま同じものが試せるということは
・TeX Live には stable だけを入れる
・GitHub には stable に加えて unstable branch を作る
しかないと思います。つまり、試してくださる方に対して
「GitHub から unstable を取ってきて、フォーマットを作る」
を要求することになります。この手間を取ってくださる方が、以前仰っていた
> 「それなりに常用している人数ヶ月試す」くらいで
> わりと洗い出されたりしませかね？
に対応すると思うのですが、多く見積もって20人程度でしょう。
pLaTeX ほど広く使われているものに限っていえば
「全 pLaTeX 利用者数」に占める「20人」は少なすぎるかと。
特に forum:1958 の「アクセント文字を含む PDF しおり」なんかは、
その20人の中でしおり常用者がいなければ盲点でしょう。
「.sty で unstable コードを動かせるようにする」
という案は、sty を TeX Live にも含めてしまうことを視野に入れています。
GitHub を取りにくる手間も、フォーマットを作る手間も要りません。
そのほうが正味のテスト回数は増えると思います。
# この帰結に「どうせ sty であって “まんま同じもの” ではない偽物だから、
# 試してもムダだ」と思われない、という仮定が入っていることは認めます。
いま Issue 9 で模索しているのは、本格的にテストしてくださる方（20人 ± α）
のための「sty をいちいち手動で \RequirePackage せず済むような自動化法」
です。
> 最後の改変でバグるかもしれないし．
は、「最後の改変一発」と「頻繁な改変」のどちらがバグりそうかと考える
と、一概にいえないと思います。
長々書きましたが、要は明確な代案が欲しいです。git にコミットする人に
とってもテストする人にとっても動きやすい代案を。