With DATACMNS-1322, Spring Data took a step forward towards better support for immutable objects using withers. However, if you have to set a larger number of fields, using withers has the drawback that you create a new instance on every wither call.
Of course you could use "the traditional way" for instantiating immutable objects: a constructor with all fields as parameters. Lombok's @AllArgsConstructor is typically used to avoid writing those boilerplate constructors.
However, in our case, we have a class hierarchy for our model classes. It is typically 1 to 3 classes deep, and every superclass has its own properties. Because Lombok's @AllArgsConstructor does not include the fields from superclasses (and probably will not in the foreseeable future), we have to manually implement an all-args constructor for every model class. This approach is quite error-prone, because when new fields are added to a superclass, you have to manually alter the constructors of all subclasses.
Recently, Lombok added the @SuperBuilder feature, which significantly improves the applicability of builders in such a case, because a @SuperBuilder includes setters for fields from superclasses. It would be extremely useful if we could advise Spring Data to use such a builder when creating instances. Then we could completely remove the (manual) all-args constructors.
Jackson, for instance, takes such an approach; you can use the annotations @JsonDeserialize and @JsonPOJOBuilder to tell Jackson to use the builder to construct the instance
Can you elaborate why you think it's a huge issue? Builders are primarily a developer convenience, both to at writing and reading time. Spring Data object instantiation is none of that. There already is an EntityInstantiator API that allows customizing the construction based on the persistence constructor's parameters. Also, there's CustomConversions, which – through its store-specific extensions – allows registering Spring Converter instances that would even allow you to take care of the entire object instance creation and population explicitly.
How far developers mitigate challenges with their object model using Lombok doesn't really play into design decisions in Spring Data.
I was actually referring to the implied severity of the report. "Huge issue" implies that either many users are affected or there's a fundamental problem with no suitable workarounds available. I don't see either of the two. Which means we are essentially back to a discussion about whether the available means to deal with this challenge are enough, and, if not, what additional complexity in the object mapping would be justified to solve an issue that doesn't seem that pressing. The ticket hasn't seen any significant feedback for four years.
I think it makes sense to evaluate how far the already existing APIs pointed to above help mitigate the problem and take it from there, potentially having an example in which challenges with the suggest approaches are described for further evaluation.