Bottom line is that bootstrapping an EntityManagerFactory prior to bootstrapping a seemingly unrelated SessionFactory influences the behavior of the latter. In particular how merges/saves are executed seem to change.

Looking at the following code:

...
	private void updateCatalogsCollection(FullTextSession fullTextSession, Catalog catalog) {
		final Transaction transaction = fullTextSession.beginTransaction();

		Consumer consumer = new Consumer();
		consumer.setName( "consumer" );
		consumer.getCatalogs().add( catalog );
		fullTextSession.persist( consumer );

		catalog.getConsumers().add( consumer );
//		catalog.getCatalogItems().add( new CatalogItem() );
		fullTextSession.merge( catalog );

		transaction.commit();
	}
...

This is the code used in the test to update the persisted entity. Depending on the test configuration, the test then checks whether the catalogItems collection has been initialized as a side effect of the class bridge on this collection iterating over it due to the made change. Interestingly, updateCatalogsCollection does not make a change to the catalog items. It turns out that in the pure SessionFactory case the change to consumers will also trigger a change event for the catalog items and hence the re-indexing of the collection and its initialization. In the case where an EntityManagerFactory is bootstrapped first, the behaviour changes and the merge does not trigger a change event for catalogItems. So the collection stays indeed uninitialized. A way to make the test pass in both scenarios is to really change the catalogItems (see commented out line). This triggers the re-indexing for sure. In fact I think it is a good idea to change the test in this manner anyway, but it still leaves the question how bootstrapping EntityManagerFactory can have such a side effect.