\symbol{#1} は \char#1\relax に展開されます．
実際のところは \symbol はrobustなので \protect\symbol(space) を経由しますが
これは今回は関係ないと思います．
・・・て投稿したら，はやてさんとかぶってました．
ところで，tlmgr update -all を 2025/11/16 現在で実行した後で
\documentclass[uplatex, dvipdfmx]{jsarticle}
%\usepackage{otf}
\begin{document}
あ葛\kchar"E0100い葛う、
あ塚\kchar"FE00い塚う。
あ曙い曙\kchar"E0101う、
あ社い社\kchar"FE00う。
\end{document}
と otf を外したり，otf で noreplace オプションをつけると異体字セレクタのところが
欠落しますね．
upjisr-h.vf のときにうまくいってないのでしょうか？
dvipdfmxが
[1
char=0x80845b(8422491)
Tried to set a nonexistent character in a virtual font
char=0x40585a(4216922)
Tried to set a nonexistent character in a virtual font
char=0x8466d9(8677081)
Tried to set a nonexistent character in a virtual font
char=0x40793e(4225342)
Tried to set a nonexistent character in a virtual font]
と四つほど対応しているであろう警告を出します．
結論を先に言うと upjisr-h.vf のときにうまくいってないのは、意図した動作になります。
uptex-fonts での SVS, IVS の開発の狙いはGitHubのこちらに記載してあります。
uptex-fonts の更新は README_uptex_font.md に記載しており、20250218 のリリースで SVS に対応とありますが、
現状をまとめると、
up{jpn,kor,sch,tch}{rm,gt}-{h,v}.vf に SVS を入れているが IVS は入れていない
up{jpn,kor,sch,tch}{rm,gt}-{h,v}.vf に SVS を入れているが IVS は入れていない
upjis{rm,gt}-{h,v}.vs には SVSもIVSも入れていない
になります。
になります。
IVSは Adobe-Japanなどを実装した実フォントとの組み合わせでないと上手く動かないという事情があります。
なのでもともと Adobe-Japanを想定している japanese-otf-uptex では作りやすいものの、特定の実フォントを想定しない建前の uptex-fonts では適切でないように思えたので IVS を入れていません。
upjis{rm,gt}-{h,v}.vf に SVS を入れなかったのは、SVSはまだ思わぬ不調がでるかもしれないという心配をして安全側にしておいたためです。
upjis{rm,gt}-{h,v}.vf に SVS を入れなかったのは、SVSはまだ思わぬ不調がでるかもしれないという心配をして安全側にしておいたためです。
懸念がないようでしたら、適当なタイミングで追加しようと思っています。