Support for both javax & jakarta versions of JAXB in the same [Java SE] classpath

Edit: ... Currently we can't support both **javax** & **jakarta** versions of JAXB in the same classpath. This looks like a migration issue for library developers.

As a library developer with a test classpath/module-path dependency on JAXB I'm looking to bump that from `javax.xml.bind` to `jakarta.xml.bind`.

However, applications often at the moment still have some dependencies using `javax.xml.bind` - it's going to take time for all the dependencies to update to `jakarta.xml.bind` (and as a library author I have no control over what apps depend on and how quickly other libraries will update to jakarta jaxb).

As the maven groupId and artifactId are the same for both `javax.xml.bind` and `jakarta.xml.bind`, we can't support both the old and the new versions of JAXB in the classpath at the same time. I believe we are going to want to support both versions of JAXB during the transition phase as apps and libraries update to jakarta JAXB.

That is, we can't have the below, as the only difference is the version, the maven groupId and artifactId is the same.
```xml


jakarta.xml.bind
jakarta.xml.bind-api
2.3.3

jakarta.xml.bind
jakarta.xml.bind-api
4.0.0

```

This makes me think this is close to a catch 22 situation. Libraries can't update to `jakarta.xml.bind` _[4.0.0]_ without breaking any apps that have a dependency on `javax.xml.bind` _[2.3.3]_. Apps can't update to `jakarta.xml.bind` until all their library dependencies have updated.

Upgrading to jakarta JAXB requires a "big bang" style upgrade where absolutely all JAXB use needs to go from javax to jakarta in that single upgrade as both jakarta and javax JAXB can't co-exist on the classpath. This is going to be tough for larger apps that have more and older dependencies.

Is there thought to releasing the new `jakarta.xml.bind-api` with a different maven artifactId _in order to support both_ `javax.xml.bind` and `jakarta.xml.bind` in the classpath/module-path while libraries and apps go through a transition phase?

No source files or tests are named. Start by reviewing the Maven coordinates and javax.xml.bind/jakarta.xml.bind compatibility described in the issue, then trace how this API is published and consumed. Done would require an agreed, implementable migration path that permits both versions during the transition.

Written by the indexing model from the issue text.