Hello,

We are currently exploring using the https://github.com/dtolnay/semver-trick to be able to give old crates the ability to convert some serialized data to more modern formats.

The basics are as follow (taking our https://github.com/zama-ai/tfhe-rs project as example):

• we have released 0.4.0 with a certain serialization format
• we plan on releasing 0.5.0 with breaking changes to the serialization
• we want to provide a way for users to update their serialization format for old data

The plan for the semver trick is:

• release 0.5.0
• update the 0.4 code base to be able to convert the old format to the new format and release 0.4.1

We have C APIs we need to be able to expose so we want to run cbindgen.

Currently cbindgen parses the cargo metadata ignoring the version of the package for which the binding is being generated

In the current prototype we randomly expand the 0.4.1 crate (which we want, it is the current workspace crate being worked, it's the old one that will expose the forward compatible conversion functions for serialization) but we also sometimes expand the 0.5.0 (as it appears as a dependency and cbindgen does not discriminate against it) which causes issues with a CargoExpand error indicating we can't specify features for dependencies. We have disabled parsing for dependencies but the flag is not considered either (it would be fine for us if it took it into account)

I believe it's possible to support the semver-trick edge case (it is very much an edge case I get that perfectly), I'm willing to contribute the patch if necessary or collaborate/answer questions on that particular thing.

I'm sure we can hack up something on our end but I think it would be better if it's a thing cbindgen supports, I don't know if cargo metadata track dependencies, but if it does I would say that honoring the "do not expand dependencies" during the metadata parsing would be an acceptable solution and maybe would avoid issues in situations where two crates may accidentaly share a name in local dev environments (though in that case the easy fix is not naming different stuff with the same name)