> Did you paste the correct snippet into "Tree generated for (2):"? Looks like it overlaps, and I suspect it is the last example without the overlap-prevention.

Right you are. Wrong copy/paste, I've updated the previous comment with the correct data.

> Probably not, but did the range position invariant checkers tell you about this problem, or did you notice it independently? If it is the latter, why didn't the invariant checks go off? Should they be updated? Or are they intentionally weakened underneath transparent positions.?

The range position's invariant checker reports no problem, I'm simply following my intuition of how it should work, which is why I'm not sure I'm doing the right thing.

The implementation of [Positions.overlaps](https://github.com/scala/scala/blob/master/src/reflect/scala/reflect/internal/util/Position.scala#L200) is surely interesting, as it doesn't match my expectations. In fact, according to that definition, two range positions don't overlap if the end of the first matches the start of the second. However, if [Locator(pos)](https://github.com/scala/scala/blob/master/src/reflect/scala/reflect/internal/Positions.scala#L240) is called on a point position such that it is included in two range positions in the same tree, then there is an ambiguity.

> I'd like to see some of this documentation transferred as you judge best into the commit comment / scaladoc for the new utility method / additional tests.

Sure I'll expand my explanation in the commit message once we have an agreement. But, what new utility method? (and, is ``new Bar() . bar/*#*/()`` the additional test you'd like to see, or something else?)