Implemented in Search 6; we still have to restore the options we used to provide in Search 5, though. And maybe to check that they still make sense, as (maybe) Hibernate ORM already handles that automatically?
Created https://hibernate.atlassian.net/browse/HSEARCH-3349#icft=HSEARCH-3349 to address these problems.

I don't think a warning in OGM is necessary.

Just make sure that Search doesn't trigger this warning

How would we do that, though? We don't know who's calling us. That's exactly why I'd prefer to have a new initializer implementation in HSEARCH. Should there be such warning? Not sure really, but having two initializer impls would leave the door open to do so.

Ok, so if you'd do that, it would be an OGM only patch. I have no strong opinion on it other than I'd not do it myself as I don't see big value in it.
Just make sure that Search doesn't trigger this warning when it invokes the multi-load API, as that would confuse people.

My point is about OGM users explicitly using the new multi-load API themselves; should they be presented with a warning (issued by OGM) if the given backend does not actually support that call and we thus need to do an entity-by-entity fallback. Or should we just do that fall-back and don't bother the user. You are right they likely won't have any other options, but you might want to learn about such shortcoming upfront instead of happily using the API and only later on finding out that it's not doing what it's promising.