How internal is internal?

Teams often want the freedom to create purely internal but public impl classes and methods that can be changed outside the constraints of semver. E.g. make a breaking API change that does not require a major version bump because no clients depend on it. However

1. Clients do depend on these things. E.g. Cloud Tools for Eclipse depends on many internal parts of Eclipse including m2e. The linkage checker itself depends on internal parts of Maven.

2. Even when clients don't directly depend on internal classes, they can get tripped up by version mismatches in multimodule projects. We've seen this happen repeatedly as a result of internal API changes in gRPC and in OpenCensus. Breaking changes inside internal packages often cause problems when different versions of multiple internal packages are in play; e.g. grpc-foo:1.25 and grpc-bar:1.67. It's not necessarily true that someone is directly accessing internal API they shouldn't be, though that could cause this too.

3. [Hyrum's Law](https://www.hyrumslaw.com/)

This affects both JLBP-3 and JLPB-4, maybe others.

For internal APIs we should recommend that their use to be limited to a single module.

No files or tests are named. Start by reviewing the JLBP-3 and JLPB-4 guidance and the linkage-checker context cited in the issue. Define the intended recommendation for internal APIs and an acceptance criterion for the resulting guidance.

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