I'm afraid I have to insist. I have read the spec, in particular, the links you provided above - thanks! That was helpful to clear up this issue to me. Yet, the more it becomes clear to me, the more I see it as a flaw. Whether it is a design flaw or an implementation flaw, I'm not quite sure, but that is also not really relevant. Let me expand.

Well, I wouldn't say it's a design flaw but well-defined behaviour. Also if you're programming to the interface you should not care about internal implementation details.

No doubt about that. I see the point that from a client point of view - the one that gets a reference to a CDI-injected bean by means of a reference annotated with @Inject - this is what we want (made precise by Section 3.2.1 and 3.3.1 of the spec).

The point is, that one should distinguish between a client point of view and an implementation point of view. The problem that this issue is about is perhaps the best example for the fact that WELD interferes with the implementation point of view, at least if the bean type is a Java interface (Note that I'm not necessarily saying that the CDI standard in general interferes with the implementation point of view). By implementation point of view I mean the one that provides a bean instance to be injected; in the example of this issue the JDK library that creates a UnixPath.

As this issue nicely demonstrates, there are situations where the implementation that provides a bean instance gets back a reference to a proxy of the bean that it provided rather than the bean instance itself. This and the following is what I mean by interfering with the implementation: the fact that the first condition stated above - P instanceof C - does not hold (in the example the proxy that is not an instance of UnixPath). Not interfering with the implementation would mean that this condition holds, at least from the implementation point of view.

We can make this more understandable. Imagine you are a bean and I'm your CDI proxy. You are a 'WELD developer' and I'm a 'Developer' (these shall be the implementation type and the bean type, respectively). Somehow the API that you are living in allows that I will be referenced by operations that normally use you. One such operation has a sanity check (line 200 of the method toUnixPath()) and asks "Hey, are you a WELD developer?". And I answer "No, I'm a Developer (and I'm not going to tell you that in fact I proxy a WELD developer).". You see the point?

To counter the surprise, look at it this way - in the class hierarchy, if you focus on implementation types, those can oftentimes classify as unproxyable types. It can be due to final methods, constructors and so on....

Out of scope. This issue, intrinsically, is about a proxyable type. Otherwise, this issue would not have come to exist.

Allow me one more comment: That something is well-defined does not imply the absence of flaws. The whole point of definitions is that they are up to someone. What that means in a larger context is another story.