As has NetBSD for that matter:OpenBSD has the express goal of supporting ancient hardware.
That said, 20 year old hardware that is still in-use today by a reasonably large amount of users isn't something I'd consider ancient or retro.
There is disagreement between OpenBSD's view on Rust's cost/benefit with a stable, reviewed and maintained C codebase and most of the rest of the industry, (and within apt) -- but again, that's not important here.
It's not limited to OpenBSD to be sceptic about Rust implementations. For one, Linus Torvalds has recently expressed his frustration on the Linux kernel mailing list with the borked rust format checking which may result in unnecessary merge conflicts. [2][3]
Also, let's not forget that while Rust is memory safe per default, it isn't a bug-free paradise. You can still have logic bugs. Of which there was one recently in the Rust implementation of coreutils, specifically '"date -r file" returns a wrong date'[4], which directly caused unattended upgrades to break in Ubuntu 25.10 [5] (or any other program that relied on a date check of a file for that matter). It goes to show that a rewrite introduces a potential for new bugs that are unrelated to the original implementation, even if that rewrite happens to be in Rust.
It feels like the movement to introduce Rust everywhere is more because Rust has become such a buzzword that everyone must use it now and less because of the capabilities of Rust. Not to throw shade, but if the only benefit is memory safety you might as well do a rewrite in any other memory safe language that provides I/O access (e.g. Haskell) instead.
Cheers, JD
[1]: https://www.netbsd.org/about/Attachment:
smime.p7s
Description: Kryptografische S/MIME-Signatur