I am just trying to understand what is the agenda here. Obviously, we are not trying to debate the necessity of profiles or their importance. The first few bullet points just reiterates what profiles are. So I do not see them adding value to the discussion here.
What I see is that you are trying to suggest an "all" profile sans all that stuff that
you consider "legacy". I understand that you want to deliver a server config that contains only the APIs that have been developed in more recent times so that the resultant config set can be Jakarta EE certified. The way I see it, the current Web Profile should be sufficient for it if someone is trying to build a simple CRUD application based on those APIs. I don't think you are taking into consideration (or addressing) the enterprise landscape which can include integration with various middleware products/platforms and portal based applications.
Microprofile already has a BOM and as I gather from various discussions, many clients are/prefer using them a la carte.
We can always revisit the scope of APIs included in the current Web Profile and include more if needed without breaking applications which are already certified on it. For those who want a more leaner config set, we can define a Web Profile "lite" version with the Servlet, CDI and a few other core APIs.
I think this should suffice for whatever we are trying to "solve" here.
P.S. I would have preferred a more modular approach similar to what Liberty is trying to achieve. But unfortunately, based on the recent conversations in the OpenLiberty forums, it seems OpenLiberty is currently being positioned (only) as an open source version of the WebSphere Liberty app server rather than an independent platform. What I would have preferred is a set of SPI specifications that are targeted for app server vendors to implement so that we could standardize on a feature based repository approach to ensure portability across vendors.
-Mrinal
_______________________________________________