This makes sense, but it does raise a composition-related observation. I created an Inspectable property wrapper that has reference semantics and conforms to BindableObject.
The specific use case in the linked example does not require it to be used with ObjectBinding because it performs a manual frame-based animation driven by a RenderClock (backed by CADisplayLink). However, in a more typical app context it would need to be composed with ObjectBinding in order to invalidate the view when the value changes.
Unfortunately, I'm not sure the current proposal offers a way to compose these wrappers in a way that is as clean as might be desired. Users would need to compose @ObjectBinding @Inspectable in that order and use _foo.value to access the Inspectable instance when injecting it into the view hierarchy. Having to use _foo.value isn't terrible, but it probably wouldn't be obvious to most users either (at least until they learned the pattern).
I have thought about tweaking Inspectable to project a Binding, having users use _foo when injecting the Inspectable instance into the preference value instead. If you add this rule then it would not be composable with ObjectBinding at all. In that world, supporting a Binding projection and the ability to compose inside an ObjectBinding would require two separate Inspectable property wrappers. I think it would get confusing for users pretty quickly to know which wrapper to use in a specific context.
I don't have any concrete suggestions to offer, but I think this is an interesting real-world example of composition. One possibility would be to bring back $$, but this time with consistent meaning. $$foo would refer to the projection provided by the wrapper just inside the outer wrapper. $$$foo would refer to the projection provided by the third layer, etc. I haven't thought through whether this is a good idea or not, but it would be one way to make all of the projections available.