For binary compatibility, which is the purpose of semantic versioning, we need to think of existing binaries (libraries and application) and not the Jakarta EE implementations.
Recompiling an existing Jakarta EE API (assuming no semantic change to the API) to change the target to Java 11 does not affect existing binaries using the API. They can continue to run unchanged on a new Jakarta EE 10 implementation which itself will require Java 11. But the existing binaries do not require any change at all.
If you change the major version of the Jakarta EE API just because you change the target to Java 11, then you signal to everyone that existing binaries using that API cannot work on Jakarta EE 10 implementations which becomes yet another major inflection point and shows instability in Jakarta EE evolution.
So if there is no change to a Jakarta EE API for Jakarta EE 10, then no need to rebuild and republish API artifacts. So the existing artifacts with target 8 are just fine.
If Jakarta EE API is getting a minor or major semantic change for Jakarta EE 10, then compile for target Java 11. Since a minor semantic change does not affect existing binaries, they will work fine with the new API running in a Jakarta EE 10 implementation on Java 11. Any code which wishes to use the changes (minor or major) in the Jakarta EE API will need source code changes and recompilation and will also have a runtime dependency on a Jakarta EE 10 implementation, so there is no downside for the Jakarta EE API artifact to be target Java 11.
So just recompiling for target Java 11 does not constitute a semantic change in the API in that existing binaries work without change. So it is wrong, and sends a bad message to the market, for us to change the major version of and API just for a change in target.
So Kevin, to your 3 bullets, I am happy with them. With respect to bullet 2, I would also be happy with just saying use target Java 11 since no new binary can use the new semantics of the API without running on a Jakarta EE 10 implementation which itself will require Java 11.