Ooh, cooll to hear you got some uptake on the call for formal methods help! Or did you end up figuring it out on your own? Either way, looking forward to the followup!
Beyond just quite possibly being slop, this is also sloppy and confused: complaining that C++ cannot remove features because they live in the stdlib forever while listing out a bevy of features that got deprecated and then removed is just oof.
Also, fun fact: Rust cannot remove anything from std once stabilised, presumably forever. Take this with a slight grain of salt, I haven't vetted this thought myself, but it's what I hear from Rust project people and I've just been in the project all-hands for three days.
Rust does partially have an easier time since it eg. does not guarantee the ABI of various std types like Vec (although the size and alignment are probably guaranteed at this point), and with 1&mut XOR N& providing local reasoning and isolation you get to change internal details easier.
They have a PR (~~closed by GitHub bot as AI slop, ironically~~ this was wrong info, it was apparently closed by Jarred himself as it missed a conversion or some 20 Zig files to Rust) to remove the Zig code.
Regarding the architecture documentation you have up on tsz.dev, one thing that jumped out to me was the use of the per node typed side pools. A semi-recent talk[0] had benchmarked this and found it to be a deoptimisation: he couldn't explain it, but an audience member suggested it is likely because an AST is not generally very type-homogenous in its visit order. After a CallExpr node the next node to visit is probably not a CallExpr but more probably an Identifier etc, so storing the node "extra data" in separate pools makes them more likely to be cold in cache rather than hot.
In Nova JavaScript engine[1] I've done exactly as you've done and split objects into typed side pools (I call them "(typed) heap vectors") but in a JavaScript engine my _hypothesis_ is that the visitation patterns are much more amenable to this: an Array, Set, or Map is more likely to be homogeneous than heterogeneous, and therefore a loop over the contents is likely going to hit the same side pool for each entry.
I have very fond memories of Kansai airport. First time I went to Japan I ... Uhh, I didn't have a visa despite going there for exchange.
The Kansai airport immigration office uttered a lot of "oohs" and "eehs", but they came through and in less than 45 minutes my appeal for deportation was accepted and I was granted a 1 year student visa. Always makes me happy when I pass through there :)
If you want to take a look at some of the "big drivers", the Project Goals[1] is the right place. These are goals proposed by the community and the language developers put together, they are not explicit milestones or must-haves, but they do serve as a guideline to what the project tries to put its time and effort on.
It's also been ridiculously slow for a month or two now :/ not a good time to be working on some relatively intricate performance optimisation with DevTools taking 1-4 seconds to even start the performance recording.
Monkey's paw: you get your wish, but so does someone who wants RAII and single-use-malloc to be left behind as a leaky and bad abstractions.
We all happily march into a future where only arena allocation is allowed, and when the arena is overfull it can only be fully reset without saving data. Copying still-used data out if it before reset is not allowed, as that's a copying half-space garbage collector. Reference counting is of course not allowed either as that's also garbage collection. Everyone is blessed...?