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.

首先閱讀目前的 JLBP-6 文字和連結的 jarsplit 重現程式。將文件中關於重疊類別的指引與 issue 中描述的 Maven 和 Gradle 行為進行比較，然後修訂 JLBP-6，使其範圍和限制準確無誤。完成的標準是：該指引不再將 Maven 特有的問題描述為普遍問題。

由索引模型根據 Issue 內容生成。