anchor.diff:  
   [NOTE]
   ====
  -By convention, Gradle will map the feature name to a capability which group is the same as the group and version as the main component, but a name composed of the main component name and the kebab-cased feature name.
  -
  -For example, if the group is `org.gradle.demo`, the name of the component is `provider`, its version is `1.0` and the feature is named `mongodbSupport`, so the feature variant will be `org.gradle.demo:provider-mongodb-support:1.0`.
  +By convention, Gradle will map the feature name to a capability which group and version are the same as the group and version of the main component, but with a name composed of the main component name and the kebab-cased feature name.
  +
  +For example, if the group is `org.gradle.demo`, the name of the component is `provider`, its version is `1.0` and the feature is named `mongodbSupport`, the feature variant will be `org.gradle.demo:provider-mongodb-support:1.0`.
   
   If you choose the capability name yourself or add more capabilities to a variant, it is recommended to follow the same convention.
   ====
  
positive.code: include::sample[dir="java-feature-variant/incompatible-variants/kotlin/producer",files="build.gradle.kts[tags=producer]"]
  ====
  
  Where, the producer declares 3 variants, one for each database runtime support:
  
  - `mysql-support` provides both the `db-support` and `mysql-support` capabilities
  - `postgres-support` provides both the `db-support` and `postgres-support` capabilities
  
negative.code: - "I provide runtime support for MySQL"
  - "I provide a Groovy runtime"
  
  And in general, having two components that provide the _same thing_ in the graph is a problem (they conflict).
  ====
  
  This is an important concept because:
  