Wouldn't it just be easier to make the rust-foo-devel package to recommend the default devel subpackage?

That said, I guess my question is, what are people supposed to expect from cargo?

Wouldn't it just be easier to make the rust-foo-devel package to recommend the default devel subpackage?

Well, that's also an option. However, it won't affect buildroot which is where problem appears.

I like the current foo/feature syntax, because that matches how you write dependent features in Cargo.toml. I think we should just make crate(foo) directly imply "default", and come up with an alternate provides just for no-default-features.

If we change the syntax, it should be in a backwards-compatible way.

I think we should just make crate(foo) directly imply "default", and come up with an alternate provides just for no-default-features.

That sounds reasonable.

Except, what would the new one for no-default-features be? Anything crate(foo/*) could conflict with existing features, so I think the one we have right now is the best we can do.

Feature names may include characters from the Unicode XID standard (which includes most letters), and additionally allows starting with _ or digits 0 through 9, and after the first character may also contain -, +, or ..
Note: crates.io imposes additional constraints on feature name syntax that they must only be ASCII alphanumeric characters or _, -, or +.

So we could just use crate(foo/-no-default) or crate(foo/--no-default) or crate(foo/+no-default) or something like that.

The constraints mentioned in the text you quoted don't mention that the name can't start with - or +, or that this might or might not be allowed in the future.

I really don't see why we need to change what we currently have. It has zero chance of clashing with upstream feature names.

It does say that after the first character may also contain -, +, or ., so that implies that the first character may not be one of the listed characters.

I still don't see a reason why we need to artificially change what we do here.

Most of the time people use default features (since it is default cargo behavior) and they do dnf install 'crate(foo)' and get non-working crate in most of the cases.

As this is the only argument that might count, but given that people should never be doing this in the first place, I'm really not sure if this is worth changing (with huge potential for breakages in the Rust stack).

but given that people should never be doing this in the first place, I'm really not sure if this is worth changing (with huge potential for breakages in the Rust stack).

Yeah. Considering that that users shouldn't interact with those virtual provides directly, consistency and stability is more important than brevity. Let's close this.