Currently only Test Containers are easy to add. Other parts of the Pax Exam System are very rigid and hard to extend.
Examples of pieces in the system that one might want to extend/change without affecting Pax Exams core:
Provisioning is currently (like all other Pax projects) tied to Pax Url. Which is very flexible but you might for example just swap out Pax URL based provisioning for the Gradle Resolver. Something that is very useful in CI builds because you can leverage all the goodies that recently came to gradle (Build Cache, Parallel Download etc). This also would avoid confusion where some parts of the build are loaded via one system (gradle, maven, sbt whatever) and the other by another one (Pax Urls Aether Client).
Allow alternative "Kernels": Implementations of org.ops4j.pax.exam.ExamSystem.
Acceptance Test API
Pax Exam already has very good APIs to run OSGi based integration tests using the JUnit4 Runner.
Almost unknown (to many i think) is currently is called "Plumbing API". It allows the user to use Pax Exam as a Harness in Tests or even as Container Bootstrapper (think Spring Boot and friends).
But, this already existing API can be leveraged by a higher level API to allow simpler Blackbox Testing Scenarios.
Support for multiple (even non-test) Container in one Test/Suite/Module
Currently only one testcontainer is allowed (or picked up). We should enable to allow a Per-Test (or even per test method) choice as we as support for Users to fire up additional containers (e.g. for client/server tests).