I would suggest that Jakarta EE version numbers are NOT the same as Java SE version numbers even though both Java SE and Jakarta EE may now have regular release cycles. This is owing to the fact that Jakarta EE versions may be required to support older versions of Java SE and keeping the version numbers same may create confusion that end-users must upgrade to the corresponding Java SE version as well.
Though, internally we may establish guidelines that Jakarta EE X should be compatible with, say, Java SE versions Y-2 and supported till Y+2 where X is the current Jakarta EE version and Y is the current Java SE version. There are a lot of third-party framework and libraries which are developed outside the Jakarta EE/EE4J umbrella and hence have different release cycles (if any). This should give end-user sufficient time to upgrade those libraries/frameworks or find a suitable replacement.
The other option may be to have Long-Term-Support versions which really mandate a minimum Java SE version upgrade while having several Feature-Releases at regular intervals which may incorporate more recent versions of Java SE. The LTS version life-cycle should align with the support life-cycle windows that most app server vendors usually have for any given version of their servers. Changing the support life-cycle window for app servers would definitely have downstream impact on application developers.