Track reverse entity references

I’m sorry, I don’t quite understand your description of the problem. What’s a “reference entity reference”? And why would you want to reindex an entity that doesn’t reference the changed entity? (Indirect references, e.g., a node referencing a user referencing a changed taxonomy term, should already work as far as I can see, if that’s what you mean.)
Please provide an explanation for clarification.

In any case, if this is too much to do with custom processors you’re using, we might not be able to support that use case. In that case, you would have to implement the necessary tracking logic yourself.

Sorry, I meant to say "reverse entity references".

The most common scenario would be a node referencing a taxonomy term, and you would want the node to be indexed again when the name, for example, of the term changes. The reverse entity reference scenario would be that you would want to reindex the taxonomy term when one of the nodes referencing it change. Why would you want to do that? That depends on the application, there could be plenty of reasons for applications with custom features.

In my case, it has to do with the Group module. You want to index the groups in which entities (nodes, products etc.) belong to so that you can customize the query to fetch only entities that the user is expected to have access to. The entity does not reference the group directly. Instead the group relationship references the entity thus it is a reverse entity reference.

The way the Group module works is a bit of a special case that would justify a custom processor, or a small contrib module - which is what I've done in my case. There is though a processor provided by Search API for normal reverse entity references and I think that should be supported by the module. The main point of creating this issue though is not to cover my specific use case. It is to see if there is a better way to architect a system that would allow custom processors to plug into the existing API i.e. getAffectedItemsForEntityChange() or something similar to determine which entities should be reindexed. Right now this is coupled to forward entity references specifically, I think it could be improved by abstracting certain part of it.

Let me know if that makes sense.

Thanks for the clarification, I think I now understand this issue better.

However, for creating a new API the question is even more pressing how wide-spread of a problem this is, especially if it might impact the performance of entity CRUD operations. (But also just if it adds further complexity to the framework.)
If this issue does already exist with our own reverse entity reference property, then that would indeed be a reason to look for a solution. Would you be able to create an automated test for demonstrating the problem using that property?