@Mrinal
The profile doesn't *handle* anything. It's just a spec/cert that you check for.
If you are a vendor implementing your own jakarta server, then you'll make sure all your fiddly bits integrate correctly (or, at least, good enough to pass the TCKs needed to tack that "JakartaEE Profile X Certified" badge on the tin). If you ever change any of your libraries/modules (be it home grown or a third party), you'll have to re-check for that cert, so that's still on the vendor.
If you are a vendor of any solution that will run on a server, and you have a hard dependency on a specific JakartaEE API, then you will explicitly document your unmet dependencies, or provide your own (and then hardcoding over it). That way, your users know what they need to look for in their servers/providers.
On the same page, if you are a JakartaEE user of any kind, you'll need to make sure you are running the app on a stack with the correct APIs available, be it by using a server with a certification for a complete enough profile, or by (once again) providing your own.
The only relevance profiles have on this is as lists of available APIs on your current environment, for you to provide any missing deps you might need.
Following your example:
1) If you have a caching solution, with your own JPA certifiable implementation of persistence, why would you care if the environment has JPA? You're still going to use your home-grown solution.
2) If you will work directly over the JPA API, then you wouldn't care about shipping your own implementation of that. You'd tell everybody they need JPA in their environment for your solution to work. Then, it'll be irrelevant what profile or environment the user is on, as long as they make sure to have a JPA implementation available.
3) If you want to distribute your home-grown solution as another JPA implementation, you're free to do so, separately from your Cache solution. Then, it follows the same logic as (2)
4) If you want to have both general JPA use, and your homegrown solution embedded into your caching solution, then you also build in some logic for the user to configure which one they want to use (or, if you're daring enough, for your solution to find out which option to switch to based on the current environment), and then switch between straight calls to the JPA API, and calls to your embedded solution accordingly.
None of this is changing, since this is how Java works (add implementations to the classpath/modpath, then call their APIs from your code), irrelevant of what we want to do with JakartaEE.
The point of profiles is to not just know an implementation of an API works on spec, but that your environment won't implode because of weird interactions *between* those implementations.
You still need to know the list of deps you need for anything to run correctly. Profiles just reduce your list from a hundred versioned deps, to a single (or more, depending on the solution we end up mostly agreeing on) versioned profile cert, plus a few dozen non-spec versioned deps.