I'd imagine the way you'd use Rust for the use case described is to have it be a library for certain protocol implementations, and leave the bulk of the application in C. Then you use very little of the standard library, and you don't call the platform APIs directly from Rust. Over many years you might port all of QEMU eventually, but over many years Rust platform support will improve too.

For things like ARM FreeBSD support, given that Rust already supports ARM non-FreeBSD and FreeBSD non-ARM, I think the blockers are likely to be random #defines for system calls (unless the FreeBSD folks are using a different userspace ABI on ARM than, e.g., Linux on ARM). Those are interesting if your goal is to reimplement QEMU in Rust, but they're not interesting if your goal is to reimplement the 9P protocol in Rust.

It looks like Windows XP is pretty well supported, and the primary reason it doesn't have official support is that the OS itself is out of support? (You can also take sitkack's suggestion of just not enabling the security-focused code on a no-longer-security-supported OS.) Rust's standard library doesn't work on OS X 10.6 because of a change in TLS / threading models in 10.7, but again, if Rust isn't opening threads or allocating memory and is leaving that all to C, you don't care.

Does the QEMU project treat OpenBSD, ia64, and Solaris as effectively more supported than what Rust calls tier 3? Do you do automatic builds on those platforms? If I report a bug that shows up only on those platforms, are developers likely to have access to such systems to reproduce them? If not, having a tier 3 build of QEMU depend on a tier 3 build of Rust seems totally fine.