It seems I misunderstood the suggestion to revert from the issue, and I am therefore closing the PR and leaving the issue to someone else, if there's interest. I already removed the dependency from VarInt of my affected crate, so this was more for the sake of other people that might be affected.

I am not an expert in Rust, therefore I am not as well-versed in the best practices.

However, here is why I think that a revert would be acceptable in this case:

• It's 0.32.9 that made a breaking change in the contract of VarInt. The fact that the code still compiles, to me, makes that worse: in the crate I'm maintaining, it was only discovered in the CI. Had there be no tests covering it, it could very easily reach a release and only be discovered with a production panic. In fact, that could still happen on software wallets depending on the ledger_bitcoin_client if they update rust-bitcoin to 0.32.9 but not ledger_bitcoin_client.
• Reverting the commit restores to the behavior of 0.32.8, so there is no breaking change unless you're relying on the behavior introduced in 0.32.9. Therefore, I think that not compiling is in fact better in this case, precisely to avoid the kind of runtime bugs that a backwards-compatible fix might cause.

That's a reasonable viewpoint, but unfortunately it differs from the Rust semver rules, as forced on users by cargo's version-matching rules.

So in order to revert this, we need to leave the error variant and constant in place, document that they're never used (and deprecate them if possible), and remove the code that produces them.

I agree that this sort of "silent" behavior change can be insidious. Hopefully, because we are reverting to the same behavior as an earlier version of the crate, and because this is in a non-central part of the API, it will be okay.

I"ll pick this up. Thanks @bigspider.