Valve's newest Linux runtime stops some .NET games starting, and the fix has no date
A future release of Steam Linux Runtime 4 will include libicu, the library whose removal stops .NET games starting at all, and the commitment comes with no version, build or date attached. It was posted on October 16 in a Steam Runtime report filed two days earlier, which is still open with 12 comments.

Resonite, the social VR app a report in the thread says cannot move to a newer Proton build while libicu is missing. Image: Yellow Dog Man Studios
Steam Runtime 4 dropped the three ICU libraries that Steam Runtime 2, soldier, and Steam Runtime 3, sniper, both carried. On Linux, .NET needs ICU for its globalisation code unless a game was built in invariant mode, so a .NET game that leans on the runtime's copy aborts at launch under Runtime 4 with a message telling the owner to install libicu from their package manager.
The reason an owner meets this at all is Proton. One report in the thread says Proton 11 forces the use of Runtime 4, which breaks the bootstrapper for Resonite and with it the ability to use newer Proton builds, since the social VR app uses the Linux runtime for its core and Proton for its renderer.
ICU was cut to keep the runtime small
The library did not fall out by accident. Simon McVittie, a Steam Runtime developer at Collabora who contributes to Valve's repository, says the removal was "an intentional change to keep the size of the runtime under control", and that the design principle is to make each new runtime as small as the team reasonably can.
That same principle is why it can come back. Adding a library during a runtime's lifetime is backward compatible and probably will not break games, McVittie says, while deleting one that was already there is a breaking change.

Battle for Wesnoth adopted Steam Runtime 4 early, and the same ICU gap was discussed with its team before this request. Image: The Battle for Wesnoth Project
A future release is the whole of the commitment
The reply is one sentence: "We've discussed this internally and a future release of steamrt4 will include libicu." There is no version number attached to it, no build and no month, and the report is open with nothing shipped.
It came from the lostgoat account, which GitHub lists as a contributor to that repository rather than a member of Valve's organisation, so the sentence is not Valve speaking on the record. It landed about 40 minutes after McVittie wrote that "the policy decision on whether to include ICU in newer runtimes is a question for Valve, I don't set the policy here", and McVittie went on to set out what adding it would mean.
The scope is narrower than the request. Only a 64-bit ICU is on the table, because libicudata in particular is large and Runtime 4 does not offer full 32-bit functionality, which both requesters said would be enough for them. The version gap comes with it: sniper carried ICU 67, and a Runtime 4 build would carry ICU 76, about four years newer and with an incompatible ABI.

RimWorld's new engine runs on .NET 10, and the request to restore libicu was filed for it. Image: Ludeon Studios
RimWorld's new engine is stuck on an older runtime
The request came from two people who say they are working on RimWorld's new engine, which runs on .NET 10. One of them says the engine is stuck on Steam Linux Runtime 2 or 1 for want of libicu, which keeps older distributions such as Ubuntu 22.04 off the current RimWorld 1.7 unstable build, because they never get the newer glibc a newer runtime would bring.
The same requester tested Unity 7.0 Alpha to be sure, and says it relies on system ICU and crashes inside Runtime 4. McVittie says the same gap was discussed with the Battle for Wesnoth team, an early Runtime 4 adopter, before this request arrived, and the Resonite report came in last, on October 17.
Until a steamrt4 build carries ICU, the fix belongs to the game. McVittie's interim suggestion is to bundle ICU 76.1 from Debian 13 with the title, which is what the two requesters are weighing against staying on a runtime four years older.
Owners on Proton's stable branch, which came back on October 12 after 49 days, are not in the firing line yet, because by that same report's account the move to Runtime 4 is forced by Proton 11, the branch whose release candidate named twelve games it had broken. For anyone already on a newer build with a .NET game, the answer sitting in the tracker is one sentence with no date on it.