Thanks for the quick response @snicoll .
I will have to check now first other changes that will come into SDN that might encapsulate this behaviour. So the additional tests will be placed in SDN and the auto configuration will just call its methods.
(Also I have noticed that I missed to add the changes for the reactive configuration to this commit)

Unfortunately how I thought the change could be done better was not successful. So I stick now to the initial solution and added the tests to ensure that only those classes with annotations that mark explicitly entities (@Node and @Persistent) or are some kind of helper entity (@RelationshipProperties) will be part of the initial entity set.

Thanks for the follow-up.

Also the RelationshipProperties type got added to this list, because the loading of those entities would fail if we are running in Spring Data's strict mode (e.g. multi store modules)

I am not sure I got that. Does adding this type fixes a bug? And if so, can we please have a test that showcases that? The tests that were added merely checked that scanning works as expect but that's not really explaining why adding that type is necessary.

In a scenario that enforces the Spring Data infrastructure to go into strict mode, implicit registration of entities are not possible (throws exception on later registration). Besides being not a prominent entity in the broader API sense, technically a RelationshipProperties annotated class is used as one internally.
As a result classes with this annotation also needs to be one of the accepted types for the set of initial entities.