Tatu Saloranta

Ok yes, I think this is the right place for the issue. This would not belong under `DeserializationFeature` since that is meant for more cross-cutting concerns (ideally not datatype-specific features,...

```Can we consider creating collection-specific feature? something like CollectionFeature. READ_NULL_TO_EMPTY? Like we have for EnumFeature? ``` Unfortunately no, as I don't like having features that overlap with other configuration functionality,...

@pjfanning I would recommend against trying make use of Fields `record` types have tho... it requires forcing access and is less than ideal, possibly breaking at some point with later...

Looking at existing `MapperFeature`, we have `AUTO_DETECT_GETTERS`. The reason I like referring to auto-detection (or implicit detection) is that this would not ignore explicitly annotated getters; only disable auto-detection --...

@yihtserns yes. On plus side, there are workarounds. On downside all these workarounds probably make it more not less difficult to fix things (since they are now behavior that arguably...

@FWest98 possibly a new issue here: chances are support needs to be added in databind for Kotlin module to use.

Note: implementation of actual handling is in `jackson-dataformat-xml` (JAXB annotations module just provides information). This sounds like: https://github.com/FasterXML/jackson-dataformat-xml/issues/197 so basically polymorphic type information would need to be combined with property...