And my response: this is a decent way of going about it, but it feels like it doesn't quite fit in with how other stuff in the Cargo manifest works. In particular, it feels weird that capabilities don't really get defined anywhere -- they are just 'provides'ed and 'requires'ed. I also worry that adding yet another concept here will make manifests using this feature substantially harder to understand.
This older Pre-Pre-RFC is also somewhat related, if you haven't done so maybe read through it and link to it as well? Pre-Pre-RFC: making `std`-dependent Cargo features a first-class concept. The still experimental namespaced-features work is also relevant reading, I think: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#namespaced-features.
Another alternative I can think of is to have ! prefixes, which you can simply use in feature values. So this:
[features]
json_foo = ["foo_json", "!bar_json"]
would amount to not allowing the json_foo feature to be selected at the same time as the bar_json feature. (Note that your basic example doesn't actually define foo_json either -- is this an optional dependency? For clarity, it would probably helpful to make it explicitly a feature, assuming that optional dependencies result in implicitly defined features of the same name.) This has the advantage that it's easier to understand in simple cases and doesn't introduce a new concept, although it will get messier in the case where you have many alternatives for a single "capability".
Finally, cc @ehuss.