I really love this example! I thought key path member lookup was a cool feature and would find great use cases but I admit I had trouble imagining what might become idiomatic usage of it until I saw this Ref example. This is really, really cool!
It also explains the purpose of storageValue quite well and I really like this addition now that I understand it better. It allows a property delegate to encapsulate its implementation publish an intentional API for the point of use.
With this feature in place I think it makes sense to only expose the synthesized storage property when storageValue is implemented by the property delegate. When the delegate itself should be exposed as a synthesized storage property it would be trivial to opt in with:
var storageValue: Self {
get { return self }
set { self = newValue }
}
In this approach a synthesized storage property would only exist when it is actually useful - i.e. when it does more than just expose var value. Delegates that don't have any additional behavior (something may be common) would just not implement storageValue.
Under the currently proposed design delegates have to opt-in to hiding themselves, but even then cannot suppress the synthesized property. The closest they can come is to use storageValue: Void.