This is extremely misleading IMO. Multiple issues were opened weeks ago about your usage of binaries. It was solely the community-at-large unaware. If there was a reason to believe the binaries directly malicious, I personally believe the community-at-large would've been made aware with it much sooner.
According to pinkforest, you also did trip cackle, a tool for automatically checking if crates exceed their claimed scope.
If crates.io wants to precompile macros in a reproducible environment, and offer them as an opt-in feature, I'd support it despite my complete and continued objections to what happened with serde_derive on a professional level and the maintainer's actions on a personal level.
My sole notable objection to this RFC/pre-RFC has nothing to do with its content, yet rather the process of introducing what's widely considered a security issue into the ecosystem to then further justify changes to the toolchain, holding the security concerns over the ecosystem (RFC commentators, project members, implementers) in the process. It's effectively impossible to fairly review this on its merit now, nor to say it isn't being reviewed on an accelerated time span than it would otherwise have been.
For actual RFC feedback, I'd like to object to
I believe this should be an error, not a yanked publication. There are several ways non-reproducible builds can be triggered. We shouldn't waste version numbers finding out a reproducible build isn't working when there's no benefit to existing with a yanked status unless there's some intricacy to the crates.io backend I'm unaware of. I'll admit inexperience with it. jhpratt seems to have raised the same comment.
Then as a question, I'd like to ask how you plan to achieve reproducible wasm builds. From my understanding, depending on the platform built from, different wasm outputs will be created. Is there a proposed mechanism other than always building from x86_64 (requiring CPU emulation, and not just containerization)?
I'd, personally, insist crates.io does verification (not that my personal insistence means anything) in order to ensure publishers don't each setup their own build processes each needing their own replication. I'd also like to note the value in crates.io rebuilding an uploaded artifact (not just performing the build) to ensure reproducible builds are possible (without multiple server-side runs).
As for watt, I do not believe it resolved reproducible builds from different host architectures.