This is addressed in the blog post linked from the release announcement: https://blog.racket-lang.org/2025/11/parallel-threads.html
> To address larger problems with the implementation and to improve performance, we started in 2017 rebuilding Racket on top of Chez Scheme. Rebuilding took some time, and we only gradually deprecated the old “BC” implementation in favor of the new “CS” implementation, but the transition is now complete. Racket BC is still maintained, but as of August 2025, we distribute only Racket CS builds
So they're billing Racket as "Mature Practical Extensible Robust and Polished". Of those I will give them "Extensible" and "Robust". You can't say you're mature and polished and practical if you've just rewritten the entire thing and deprecated the legacy codebase to support new features that have been in other languages since forever.
Maybe they were talking about Racket 8.0 and didn't change the website yet?
Fears about refactoring introducing bugs are fine and valid - but after eight years, haven't really happened. Seems the extensive test suite did its job.
This isn't a case of Python 2 v 3. Packages weren't broken en masse. The API remained stable.
If anything, the rewrite has proved that it is mature. Because they could perform a refactor without breaking everyone's everyday.
For example, I found a bug running the tests of the r7rs package, it was simplified to a bug in "plain" Racket and later fixed, 3 days after the initial report. It was in June 2019 https://github.com/racket/racket/issues/2675 Note that at that time, the default version of Racket was he old one (before the rewrite).
Racket is lead by professors, and (as is sometimes the case in systems research) some of them are very highly skilled software developers, well above HN average. But they have not been working in industry, and some have never worked in industry, so they don't always know what notes to hit, and they don't always know current subtleties of practice.
My best example of this is when someone kept saying the platform was "batteries included". My reaction was, my god, no, please don't say that: the first time the wrong person sees that, invests time with that expectation, and finds all the ways that is absolutely not true by industry convention, they will rip the ecosystem a new one.
Set expectations properly, and you attract the right people, who will love it, and they will also disproportionately be great programmers.
That said, the software engineering quality situation is much better than the impression you seem to have. They've done a very solid job of rehosting Racket internals, and of generally maintaining backward-compatibility over the years. Much better than Python, for example. (Also, Racket docs are usually much better than most ecosystems I have used in recent years.)
The short story is the same as anything written in C: it's an unwieldy language.
I'd also note that Chez Scheme was a commercial implementation bought and open-sourced by Cisco. It wasn't something they threw together. Because it is a complete scheme v6 implementation they are building on instead of rolling their own implementation in C. Coding against a stable Scheme API has to be easier and less buggy than what they had before (not to mention Chez being much faster at a lot of stuff).