Optional features are part of the crate — the project should say so

epage:

We will likely never directly support .cargo/config.toml fields in Cargo.toml. Instead, we will need to look at how they should be abstracted in Cargo.toml.

This plan means package/workspace .cargo/config.toml will continue to need to exist indefinitely. I don't like that.

What would be so bad about moving everything, and I really do mean everything , from .cargo/config.toml to Cargo.toml, right now, so that we can deprecate the existence of .cargo/config.toml in packages and workspaces as soon as possible?

You could still migrate these settings to a better schema within Cargo.toml, later, probably on a setting-by-setting basis. It seems to me it would go more smoothly overall.