I agree that some test utilities are to be considered as APIs.
But if some classes in tests are famous for being used as APIs in downstream projects, why have they been marked as internal for so many years at the risk of seeing such non-backward compatible change happen at some time?
IMO, if some project clearly needs this code as API, then the code should be API and not "x-internal". We have strong capabilities to prevent API breakage, and they can be leveraged easily both in IDE and a buid-time; so there is no technical issue here.
It would be worth reviewing ObjectTeams test and identifying some JDT packages to treat as API and remove the x-internal, to prevent from similar errors in the future.
However, I totally disagree that the code cleanup in particular is the issue here; this change is technically and in terms of governance very correct; it just highlighted some other problems in JDT (non-)APIs and/or downstream project synchronization.
I think the real issue is that with more contributors, the JDT project evolves faster than it used to, and as a consequence, can break things faster for downstream projects that relied on unreliable things.