For a producer method that provides a bean that implements interfaces from 2 modules (A and B, where B depends/requires A), the proxy class name might be based on the interface name of the more general module (A) which then leads to using the Java Module of that class for accessing the MethodHandles.Lookup. During class definition this leads to an error though, because module A does not read module B, so the bytecode of the proxy which refers to types of module B fails verification.

Here a simplified code example:

interface A {}
module A {
  exports ...;
}

interface B extends A {}
module B {
  exports ...;
  requires transitive A;
}

class MyProducer {
  @Produces
  @ApplicationScoped
  B produceB() {
    return null;
  }
}
open module App {
  exports ...;
  requires java.inject;
  requires jakarta.enterprise.cdi.api;
  requires weld.core.impl;
  requires B;
}

A possible fix is to use the bean class as base for the package for proxies in org.jboss.weld.bean.proxy.ProxyFactory#createCompoundProxyName which I am curious about. Why wasn't this done this way before? It's strange to see a proxy named A$B$... when the proxy is for the type B. I don't care about the name, just find it odd, but the proxyPackage must AFAICS use typeInfo.getPackageNameForClass(bean.getBeanClass()) to work properly in module mode.