The problem with cargo features is they’re meant to do exactly one thing, and that is to represent additive API additions only. As soon as you try to use them to represent things which are mutually exclusive, things tend to fall apart. The way cargo features work, two downstream crates can request different features from your crate and cargo will build your crate once with all the features that were requested. If they requested mutually exclusive features, well, now what?
can be set in Cargo.toml of the parent crate
Why would the parent crate care about whether a library is being linked to statically or dynamically? The only entity who should care is the user building their application. Maybe
clang-sys is some deep transitive dependency. How is the user going to specify how they want clang linked?
Also to answer your original question, no, you cannot have a different set of default features for each target. Also, I really hate default features because if I have a transitive dependency with some default features and I don’t want those default features, unless the crate which pulled in that transitive dependency remembered to disable that default feature, I am powerless to turn off those default features.
I really hope someone writes up a proposal for a better way to let the user configure aspects of a given, possibly transitive, dependency.