The use of references resolvers is very limited, because you don't have access to the component node or property name of the handled property like you do in ui components with the ValueContext.

This makes it very difficult to implement business logic like simple calculations or referencing external data. A very simple example would be two properties you want to multiply and return the result to the frontend. Closest to what I need is getting the main content node from the aggregation context (the component node is always null at that point) and search for a specific component node. This is a limited and ugly solution, off course. 

Also ReferenceResolvers are only bound to a property name, that means if you want to for example resolve an image property in two different ways, you need to use different property names. This makes it hard to keep an overview in large projects. Also there is no good way to change the resolving of a property afterwards. Let's say you have an image in two components and at first you want to resolve it the same way in both components, but later on requirements demand them to be resolved in different ways. You will have to rename all properties in the JCR or you should use different property names from the beginning? Giving a prefix or suffix containing the component name?

I would suggest to connect reference resolving to the component definitions the same way it is already done when using templating model classes.  

Also currently you can't just add values to the JSON of a component without hanging a resolver to a property that must have a value. This is why occasionally I had to define a dummy property with a default value to trigger a reference resolver in a component.

Attached you will find a simple resolver class demonstrating the main issue.