I'm not too worried about having a V.ref with its own members - after all, V.ref should be a language fiction (for the VM, the only real thing is V). So, in my mental model, it will be javac, not the VM, to do most of the lifting here. Am I wrong in my assumption?
The VM team has expressed a preference that these members not be duplicated, so we're exploring alternatives. One alternative that has been suggested is: if X is a reference projection of V, then `invokeinterface X.m()`, be adjusted to look for members on V. (Some adjustments would be made to the resolution for the case of private implementations, where the access check would be relaxed on the implementation _class_ but not the _member_. This sidesteps the problem with the obvious solution (interface methods on V.ref) having to do with non-public methods.)
