The quickcheck crate has released version 1.0 a while back.
Looking at the git history, it seems the changes between 0.9.3 and 1.0.0 were fairly minor, so in most cases I suspect this can be addressed by patching dependencies.
This new version itself depends on: - rand 0.8 (unstable only has version 0.7.3-3)
In general when looking at dependency bumps, I often use the blame feature on github and similar sites (which IME are far easier to use than the command line git blame) to see if any other changes were made at the same time as the dependency bump upstream. The changes for rand 0.8 look relatively small and easy to back out to me. https://github.com/BurntSushi/quickcheck/commit/319145dfb9e8e1f2d405276bb88ac03b7f56aca3 I think it probably makes sense to do a rust-rand 0.8.x transition at some point in the not too distant future , but I would personally wait until other transitions such as futures/tokio and the rust gtk stack are over.
- env_logger 0.8.2 (unstable already has 0.9.0-1)
rust-quickcheck was already patched in Unstable by a NMU to use env_logger 0.9, so I can't see this being a problem.
librust-im-rc+quickcheck-dev 15.0.0-1 depends on librust-quickcheck-0.9+default-dev, librust-petgraph+all-dev 0.5.0-1 depends on librust-quickcheck-0.9-dev | librust-quickcheck-0.8-dev, librust-petgraph+quickcheck-dev 0.5.0-1 depends on librust-quickcheck-0.9-dev | librust-quickcheck-0.8-dev,
It doesn't look like these feature packages have any reverse dependencies, so worst case, they could be dropped if they can't reasonablly be fixed. (I suspect they will be easy enough to fix though)
Source packages in unstable whose autopkgtests are triggered by rust-quickcheck:
rust packages in Debian generally have "skip if uninstallable" set on their autopkgtests. So these aren't directly blockers (though it would be nice to fix them if possible).
This might be a kind of messy transition, so i'm opening this ticket to keep track of it.
It doesn't look that bad to me.

