Thanks Mariano for addressing it from multiple perspectives.
I am trying to emphasize that we should also take the implementations into consideration rather than just talking about the profile as a certified aggregate of individual specs. By implementation, I mean
not only
implementations of specs, but also value added container services for each app server vendor and external service providers.
The current Eclipse platform with the Equinox P2 repository addresses this very efficiently. Even though we have multiple official "eclipse packages" - consisting of various combination of features, everything just works consistently for everyone - whether developers using it as an IDE or RCP app builders.
So if we approach Jakarta EE profile in the lines of an Eclipse package distro, a lot of those inconsistencies (in terms of different implementations) can be avoided within the ecosystem of a single app server vendor (read their enterprise platform). Whether its a app server vendor providing distinctive value added container services on top of various low level Jakarta EE specs or various third party service providers providing their niche services on the enterprise platform - everybody would have a single repository to pick the certified implementations (not just specs) so long as they are in the same app server vendor's application platform within any given Jakarta EE version.
All that app server vendors would have to do is to provide a light-weight kernel (something similar to WSO2 carbon) and a standard way to pull in the relevant bits via a product configurator which can be commonly used for introspecting dependencies for Jakarta EE apps as well as vendor's container services and for third-party service providers.
Each app server vendor would have their own Equinox P2 (or some form of OBR) repository with certified implementations of specs for any given Jakarta EE version. If this can be achieved, then perhaps we won't even need profiles. Solution providers would just need to certify their solutions on app server vendor's platform version (associated with Jakarta EE version) rather than certifying it on various Jakarta EE profiles (such as web, full etc.).
This is very similar to how applications are certified on any Linux distribution even when different distributions may have different set of packages in their profiles (such as desktop or server). In this case, the packages that each distro bundles in a profile (say desktop) vary greatly from vendor to vendor. But since applications are certified against the platform (rather than a profile) things work consistently across all possible combinations of packages.
Implementing a similar approach in Jakarta EE would mean standardizing on the concept of such a repository which could be consistently implemented across "application platforms" of each vendor. Osgi already provides much of the foundation for implementing this and we already have WSO2 taking a step in this direction with their middleware platform.