Copying the comments from the PR here, since the commits are now obsolete (targeting Search 5 instead of Search 6) and I had to close the PR:

Anyway... as shown on this build, switching to field storage brings a few challenges:

• Elasticsearch doesn't store time zone information for dates, so we lose some information when storing/retrieving some types of fields, such as `Calendar` or `ZonedDateTime`. This could be solved by adding bridge-defined fields containing only the time zone/offset for such types.
  See how `ElasticsearchDateCalendarBridgeIT` or `JavaTimeTest.testZonedDateTime` fail, for instance.
• We use the `indexNullAs` feature in Hibernate Search to populate the `null_value` attribute in the ES mapping, which has the effect of making documents with a null in a field match some search queries on this field, by assuming that null is in fact some pre-defined value.
  Unfortunately, this pre-defined value is also returned for null fields when retrieving the stored value. So `ElasticsearchIndexNullAsIT` now fail, because when we store `null`, we expect to retrieve `null` when projecting, but we get the `indexNullAs` instead.
  See how `ElasticsearchIndexNullAsIT` fails, for instance.
• Elasticsearch seems to store timestamps with millisecond resolution, while date/time objects in Java 8 have nanosecond resolution.
  See how `JavaTimeTest.testLocalTime` fails, for instance.
• For some reasons spatial projections seem to fail with this patch, but I'm fairly confident it's related to my changes and not to Elasticsearch. I'll look into it if we decide to go this way.
  See how `SpatialIndexingTest` fails, for instance.