QUARKUS-2213, QUARKUS-2214, QUARKUS-2215 and QUARKUS-2216 all describe situations, where there is some transitive dependency T of a supported Quarkus extension QE such that T is not managed neither io.quarkus:quarkus-bom nor com.redhat.quarkus.platform:quarkus-bom but it is managed by another Platform participant P. P manages T at a community version because it is not required by any of P's supported extensions.

Side note about packaging the zipped Maven repo using PiG :
We currently resolve all extensions individually against com.redhat.quarkus:quarkus-universe-bom. It might be seen as more appropriate to resolve them against the union of all generated participant BOMs. But, first, Pig does not support resolving against multiple BOMs yet. The change is merged, but not released yet. Second, that union should be equivalent to what we have in quarkus-universe-bom, so the way PiG resolves should be methodologically correct. (I do not think we should resolve each participant's extensions only against its own BOMs - i.e. core extensions only against com.redhat.quarkus.platform:quarkus-bom and Camel extensions only against com.redhat.quarkus.platform:quarkus-camel-bom and com.redhat.quarkus.platform:quarkus-bom. That would IMO bring duplicate artifact versions that we want to avoid.)

As a result of the above, the transitive T is seen as community version by PiG and is thus not included in the zipped Maven repo.

As a further consequence of the above, some Quarkus quickstarts cannot be built against the zipped repo and Central. This caused by the fact that they import only com.redhat.quarkus.platform:quarkus-bom (and no other BOM) where the T constraint is not present. T is thus resolved as prod version through the normal dep chain but that prod version is not available in the zipped Maven repo.
It is irrelevant whether the test also uses https://maven.repository.redhat.com/ga. It can and the prod version of T can still be missing.

Possible solutions:

I am not sure how much general the solution should be. I can think of the following variants:

A. Minimal, product only

We could aim at solving this only in the prod platform and only for the prod extensions. So if any participant manages something required by a supported extension (coming from any other participant), then the prod version constraint should be added to all impacted participant BOMs.

B. General, prod and community

Or we could aim at solving this in general for all extensions: if any participant manages something required by an extension coming from any other participant, then the newest (prod being newer than anything else) version constraint should be added to all impacted participant BOMs.