端末 ID で VT420/520/525 に設定すると、vttest で最初にReturnを押さないとメニューが出なくなっていた。
この事自体は端末 ID を増やした時に気が付いていたのだが、原因だと思っていた DA3 に対応しても現象は変わらなかった。

という事でまじめに調査。
ログをとってみると、DECRQSS が飛んできてるなあ。
DECRQSS は現在の設定状態,動作状態を問い合わせる為の制御シーケンス。
例えば、現在の文字表示属性(下線付きとか色とか)や、上下マージンの位置、保護属性の状態などを問い合わせられる。
問い合わせられる設定は沢山あり一つずつ対応していかないをいけないので、どの問い合わせに対応するか選ぶ必要がある。
# 実際のところ、設定変更自体に対応していないものが多いし

で、vttest は何を問い合わせて来ていたかというと DECSCL (端末動作モード)。
それって DA1 での機種問い合わせと大して違わないじゃん。
まあ対応は簡単なのでさっさと実装してみたところ、vttest で最初に Return を押さなくてもよくなった。
ついでに ctlseqs.txt で DECRQSS で問い合わせ可能な設定にも対応させた。
# 多分 xterm が対応している分

作業後、vttest で DECRQSS 対応の確認テストを行ってみたら、なんか変。
正常な応答と不正な応答を逆に判断されているっぽい。
VT520 のリファレンスマニュアルでは、

<DCS> 0 $ r Pt <ST>   -- 正しい要求に対する応答
<DCS> 1 $ r <ST>      -- 不正な要求に対する応答

となっているのだが、ctlseqs.txt では 0 と 1 が逆になっている。
自分は VT520 のリファレンスマニュアルを参考に実装したのだが、vttest は ctlseqs.txt (xterm 付属のドキュメント) に従っているのか。
まあ、vttest と xterm はメンテナーが一緒だし、当然と言えば当然か。

DECRQSS 自体は名前が印す通り DEC の Private な制御シーケンスだから DEC のドキュメントを信じたい所だけれど、マニュアルの誤植という可能性もある。
他のソースも確認してみようと、まず all-escapes.txt を見ると、これは ctlseqs.txt と同じだった。
all-escapes.txt には情報のソースも挙げてあるのだが、これは Reflection になっていた。
次に確認したのは VT420 のマニュアル。こちらは VT520 のマニュアルと一緒。
うーん、どうしよう。 やっぱ確認用の実機が欲しいなあ。

どっちに合わせるか迷ったが、誤植という事もなさそうなので、とりあえず DEC のマニュアルに合わせる事にした。