5/23にtexlive 2019をWin10上でフル・インストールし、早速 tlmgr update --self --all し、過去のuplatexでコンパイルしたソースで試しました。快調そのものでした。で、今日5/24にtlmgrで同様の操作をいたしましたら、エラーです。試しに uplatexを疑い、tlmgr restore uplatex 50811いたしましたら、正常になります。根本的には uplatexの問題と思いますが、正常動作するrivisionがでるまで、毎日tlmgr update --self --all した後に必ずtlmgr restore uplatex 50811をするのも面倒で、標題のようなオプションがあればいいな、とおもいます。どなたか過去に同様のご苦労された方もおられるのではないでしょうか？
因みに、texソースとエラー・ログをやや重いですが示します。
> ! Undefined control sequence.
> \@title ...} {\normalsize（新字新仮名）
このエラーですが，upTeX v1.24 のバグ回避のために
uplatex に入れた回避策が，逆に悪さをしているということですね。
upTeX v1.24 にはバグがあり，科研費 LaTeX のような全角数字を含むマクロが使えなくなった
https://github.com/texjporg/tex-jp-build/pull/79
→ 全角数字を含むマクロを作れるように，ukinsoku.tex で \kcatcode を 16 に変えた
https://github.com/texjporg/uptex-base/issues/3
→upTeX v1.24 のバグの影響？で，結果的に全角かっこも 16 になってしまった
→マクロ名称の区切りスペースが“（”の前に無いと，繋がってしまい Undefined になった
ttk さん
やっぱり upTeX のリビルドを申請し，v1.25 に上げた方が良いような気がしてきました。
ご意見お願いいたします。
> \@title ...} {\normalsize（新字新仮名）
このエラーですが，upTeX v1.24 のバグ回避のために
uplatex に入れた回避策が，逆に悪さをしているということですね。
upTeX v1.24 にはバグがあり，科研費 LaTeX のような全角数字を含むマクロが使えなくなった
https://github.com/texjporg/tex-jp-build/pull/79
→ 全角数字を含むマクロを作れるように，ukinsoku.tex で \kcatcode を 16 に変えた
https://github.com/texjporg/uptex-base/issues/3
→upTeX v1.24 のバグの影響？で，結果的に全角かっこも 16 になってしまった
→マクロ名称の区切りスペースが“（”の前に無いと，繋がってしまい Undefined になった
ttk さん
やっぱり upTeX のリビルドを申請し，v1.25 に上げた方が良いような気がしてきました。
ご意見お願いいたします。
> 全角の約物（記号類）の \catcode が変更されたためだと思いますが，
> 現状では全角約物は普通の文字として扱われているという理解です．
> それが新たなルールであればそれでも良いとは思いますが，
> 過去のソースが通らなくなるのは困ります．
いえ，これは TeX Live 2019 に入っている upTeX v1.24 のバイナリのバグです。
（意図したルールではありません）
https://github.com/texjporg/tex-jp-build/pull/79
しかし，バイナリは年に一度しかビルドしないのが基本的なルールなので，我々としては
「日本にとってよほど critical でなければリビルド依頼は出さない」
という前提で，
「バイナリをリビルドしない範囲で，マクロレベルの設定で
どうにかバグを隠せないか？」
と試行錯誤していたんです。この辺の経緯は
https://github.com/texjporg/uptex-base/issues/3
で開発者間で議論していました。
しかし，結局今回の forum のトピックが立ったことで，やっぱりリビルド申請
するしかないな，と私は思った次第です。
> 現状では全角約物は普通の文字として扱われているという理解です．
> それが新たなルールであればそれでも良いとは思いますが，
> 過去のソースが通らなくなるのは困ります．
いえ，これは TeX Live 2019 に入っている upTeX v1.24 のバイナリのバグです。
（意図したルールではありません）
https://github.com/texjporg/tex-jp-build/pull/79
しかし，バイナリは年に一度しかビルドしないのが基本的なルールなので，我々としては
「日本にとってよほど critical でなければリビルド依頼は出さない」
という前提で，
「バイナリをリビルドしない範囲で，マクロレベルの設定で
どうにかバグを隠せないか？」
と試行錯誤していたんです。この辺の経緯は
https://github.com/texjporg/uptex-base/issues/3
で開発者間で議論していました。
しかし，結局今回の forum のトピックが立ったことで，やっぱりリビルド申請
するしかないな，と私は思った次第です。
コメントするか悩みましたが，事情に詳しい方の意見があれば伺いたいです。
> バイナリのバグなのですか？だったらバイナリを作り直すのが筋だと思います．
それはその通りですが，世界中のバイナリビルダーたちの手間を取ることになるので，
リビルドしないに越したことはないというのが私の感覚でした。
(今回はその判断が間違っていたことに気付かされたわけですが…)
基本的には，「セグメンテーション違反などのセキュリティ修正」や，
「そもそもバイナリが使い物にならなかった」くらいの大事でなければ
バイナリのリビルドが行われないケースが多いような印象です。
> 今でもかなりの数の修正が毎日のように落ちてきますが，バイナリも含まれているのではないでしょうか？
今年は今のところ dvips と dvipdfmx だけです。
どちらも世界中で使われているプログラムで，セキュリティ修正が入ったように見えます。
影響が大きいと判断されたのでしょう。
(この辺り，明確な基準はないと思うのですが…。)
> バイナリのバグなのですか？だったらバイナリを作り直すのが筋だと思います．
それはその通りですが，世界中のバイナリビルダーたちの手間を取ることになるので，
リビルドしないに越したことはないというのが私の感覚でした。
(今回はその判断が間違っていたことに気付かされたわけですが…)
基本的には，「セグメンテーション違反などのセキュリティ修正」や，
「そもそもバイナリが使い物にならなかった」くらいの大事でなければ
バイナリのリビルドが行われないケースが多いような印象です。
> 今でもかなりの数の修正が毎日のように落ちてきますが，バイナリも含まれているのではないでしょうか？
今年は今のところ dvips と dvipdfmx だけです。
どちらも世界中で使われているプログラムで，セキュリティ修正が入ったように見えます。
影響が大きいと判断されたのでしょう。
(この辺り，明確な基準はないと思うのですが…。)
ここ↓を見ていると、年1回が原則だが、やむを得ず年2〜3回になってしまう年がある、という感じでしょうか。
https://www.tug.org/svn/texlive/tags/
Karlさんの TeX Live ML のお言葉にありますように、
「毎年のようにリリース後に問題が発覚してrebuildを迫られていて、今年は無いように願います。しっかりpretestしましょうね。」(超訳)
とのお話があった中で、今年は既に2回あって3回目をお願いしている状況でして、各方面に申し訳ないです。
今でもかなりの数の修正が毎日のように落ちてきますが，バイナリも含まれているのではないでしょうか？
おそらく TeX Live の中で Master の下 (マクロ類等、バイナリーであっても全プラットフォーム共通、多くがCTANのコピー) と Build の下 (プラットフォームごとにコンパイルが必要) の違いがあると思います。もちろん、開発者側の影響の範囲が大きく違います。
今回の upTeX 1.24 の件は、Build の下 の方でして「かなりの数の修正が毎日のように」の方ではなくて「年1回で済ませたい」方です。
済みません、解決したと言いましたが、別のソースで、コンパイルしましたが、やはりエラーがでます。log file あらためて添付します。初心者につき対処法がわかりません。これも、前回と同様に tlmgr restore uplatex 50811 と、前のrevisionに戻すと、コンパイルは通ります。