Though about this as well, but is there a real use case for this?

For a client proxy you might want to unwrap the current contextual instance . So maybe we should define two interfaces, something like WeldClientProxy extends WeldConstruct?

Hmm, as means to obtain metadata? Isn't it easier to just use BeanManager.getBeans() ?

For this you would need a correct bean type which is not always that easy to obtain.

add possibility to distinguish client proxies (contextual reference) and intercepted subclasses (contextual instances)

Though about this as well, but is there a real use case for this?

allow to obtain javax.enterprise.inject.spi.Bean<T> for client proxies

Hmm, as means to obtain metadata? Isn't it easier to just use BeanManager.getBeans() ?

Two more "features" come to my mind:

• add possibility to distinguish client proxies (contextual reference) and intercepted subclasses (contextual instances)
• allow to obtain javax.enterprise.inject.spi.Bean<T> for client proxies

Ok, any particular thoughts on how to do that?
I was thinking of adding an empty (marker) interface to API which all our proxies would implement. Therefore anyone having a dependency on API could do a simple check such as
object instanceof WeldProxyMarkerInterface.

Furthermore, we could also provide a simple interface with boolean method for this check.

manovotn I think we should address this in the next Weld 3 API version, i.e. 3.0.SP1.

Since 2.3.0.Beta1 and 3.0.0.Alpha11 classes generated by Weld are marked with the SYNTHETIC modifier.

Related https://forum.hibernate.org/viewtopic.php?f=26&t=1039523