JLBP-6 is misleading regarding "don’t publish the same classes under multiple Maven IDs"

The current text is

>Whether or not you make breaking changes, don’t publish the same classes under multiple Maven IDs; this creates a situation where artifacts have “overlapping classes.” Another best practice, [JLBP-5](https://jlbp.dev/JLBP-5), covers how consumers need to handle such problematic scenarios — don’t create new cases!

However, in practice this is a Maven-only flaw.

Gradle can handle diamon dependency resolution automatically, and Gradle does enable publishers to evolve their libraries with backward compatibility in mind.

For example:
* `commons-compress-1.0.jar`: a single jar with all the compressors (gz, tar, zip)
* `commons-compress-1.0.jar`: no classes, just a pom artifact for backward compatibility. It would depend on all the other `commons-compress-*-1.1.jar` artifacts
* `commons-compress-base-1.1.jar`: base interfaces, no compressor code
* `commons-compress-tar-1.1.jar`: only tar-related classes
* `commons-compress-gz-1.1.jar`: only gz-related classes

Gradle enables publisher to declare platform constraint (see https://blog.gradle.org/alignment-with-gradle-module-metadata), so the resolver would automatically resolve the diamond.

With Gradle platform in mind, `commons-compress-base:1.1` could add `platform` constraint on `commons-compress:1.1`.
It will let Gradle know that if it sees `commons-compress` on the classpath, it should bump it to at least `1.1`.

That fixes diamond dependency.

I've published a reproducer project: https://github.com/vlsi/jarsplit
It works fine with Gradle and it fails with Maven, so it highlights that the bug is Maven tool-related only.