@hsivonen, I feel and have felt your pain with cfg-if and other dependencies that increase MSRV in patch releases. To preserve my crate MSRVs (and policy) I've gone so far as to cut PATCH releases with additional version constraints such as the following:
# Unused, transitive constraint to preserve our MSRV
# cfg-if (via log) 0.1.10 release has MSRV 1.31.0
# alexcrichton/cfg-if@171ba7f
cfg-if = { version=">=0.1.2, <0.1.10" }
In another place I decided not to use cfg-if, given its lack of MSRV policy. Or, more recently:
# A tempfile dependency, max transitive for MSRV 1.39.0
# https://github.com/Stebalien/tempfile/issues/120
remove_dir_all = { version=">=0.5.0, <0.5.3", optional=true, default-features=false }
While tedious, the approach has worked. I'm able to fulfill my end of the MSRV contract. Once I do raise my MSRV (destined for a MINOR or MAJOR release), these workaround constraints get removed.
Speaking of which, my marked crate has an encoding_rs dependency. In this case I've lucked out though. My MSRV is currently 1.38.0 which is higher then your increased, no-longer-guarunteed MSRV estimate of 1.36.0! The latest encoding_rs is 0.8.26. This is a great crate, thank you! As this crate is broadly used and the API appears stable, have you considered releasing a 1.0.0? Then you could possibly offer that you'll only intentionally increase MSRV in a MINOR release? (Since MINOR releases are semver compatible, post 1.0.0, the hope is this isn't onerous.)