I think this raises some interesting questions around the goals of Jakarta EE.
How important are (or were) the portability aspects? Is switching app servers/vendors something that is common to do for Java EE deployments? In my experience it's not, the ability to switch vendors is a perceived value for many users, but one that never actually gets exercised in practice, however my experience may not be representative.
However, there is another aspect to portability, and that's third party (eg open source) libraries and technology building on Java EE - the fact that a single library can run on many different vendors implementations is highly valuable and probably one of the biggest contributors to Java EE's success. That said, there's not a lot of cases that I've seen where open source libraries that depend on Java EE depend on the whole of Java EE, they tend to depend on a limited subset of specs. This I think would be generally compatible with a composable palette approach to Jakarta EE, as you suggest. There's certainly some scenarios where there may be problems, but in practice I would expect those to be rare and manageable.
Another major goal and advantage of Jakarta EE, as I see, is portability of developer skillsets, which enables companies to select a particular implementation, but be able to hire skilled developers from a much larger pool of experience over many implementations. A composable palette approach doesn't impede this goal at all.
I'm certainly for this direction.
