Hi,
thanks for this proposal, I love the idea of improving the dirty checking and try to skip some more unnecessary indexing work.

Let's also consider that we had a similar requirement which is to know - in case of custom FieldBridge implementations - which index fields will be written (name and field options need to be known).
This was recently improved by introducing org.hibernate.search.bridge.MetadataProvidingFieldBridge but we're considering this a temporary solution - to not break existing APIs - as we have plans to redefine the FieldBridge API in version 6; at that point I hope we can express this in a more elegant way.

For the dirty-checking problem you need to know which entity properties are being used by a custom FieldBridge (or ClassBridge), which is slightly different but this could be considered as a different aspect of the same API, so we should keep this requirement in mind as well.

To clarify: this only applies to an entity which is using a ClassBridge right?
For fields of an entity which is not using such a bridge, I would expect the indexing engine to be able to figure out that a specific entity property is not going to be read, without even needing an annotation. Wondering if we can avoid the additional annotation and still do the right thing.