ATM, the treatment of .ref and .val tokens by javac is rather crude and hacky - just good enough to prototype/enable experiments with the use cases we are concerned with

The following code extract shows what we do when we encounter
.val or .ref in source code.

{code}
       /** Determine symbol referenced by a Select expression,
         *
         * @param tree The select tree.
         * @param site The type of the selected expression,
         * @param env The current environment.
         * @param resultInfo The current result.
         */
        private Symbol selectSym(JCFieldAccess tree,
                                 Symbol location,
                                 Type site,
                                 Env<AttrContext> env,
                                 ResultInfo resultInfo) {
            DiagnosticPosition pos = tree.pos();
            Name name = tree.name;
            switch (site.getTag()) {
                // ... various ...
            case CLASS:
                // ... various
                if (name == names.ref && site.isValue() && resultInfo.pkind.contains(KindSelector.TYP)) {
                    return site.tsym.referenceProjection();
                } else if (name == names.val && site.isValue() && resultInfo.pkind.contains(KindSelector.TYP)) {
                    return site.tsym;
                }
            // ... various
{code}

https://bugs.openjdk.java.net/browse/JDK-8244229 is raised with the objective of making the handling of these tokens robust in the context of classification/meaning/scope of names in the manner of JLS chapter 6.

This ticket is raised for the specification changes needed.