Brett Meyer Unfortunately I don't know "what's still necessary", let alone a concise list

To your specific list:

Ensure users can explicitly override the CL used, rather than making assumptions about the "requesting bundle" CL. This may actually clean up a few other caveats we have documented. Steve Ebersole, I know you mentioned this may already be possible, but maybe it needs better wiring-into the OSGi environment?

The CL used can always be redefined. However for the user to do that, they need access to (1) the Hibernate BootstrapServiceRegistry building to hook it in and (2) access to the concrete ClassLoader(s) that they want used at that time (or some contract through which it can be obtained just-in-time). I just don't see how that happens in OSGi.

And as far as using TCCL... not going to happen. In fact such a suggestion really makes my blood boil. This is in fact how Hibernate operated for nearly a decade. And we got chided/ridiculed for that specifically from the OSGi community.

Use the aggregated CL (or OsgiClassLoader) within JavassistProxyFactory, if this hasn't been resolved already.

This work is already done in fact.

A BundleListener, similar to HHH-10346, was necessary only when the OsgiClassLoader was incorrectly shared through the Activator. Since that's no longer the case, and it's isolated for each SF/EMF, we may be all set here.

I have no idea about this one. From my limited OSGi understanding I believe the changes I made mean we no longer need a BundleListener for this specific purpose. As you said, the OsgiClassLoader and class-loading in general is now isolated per bundle.