I am a bit worried that merging this would break existing applications that rely on the fact that their listeners are not called on forms that have theinherit_data option enabled.

Should this behavior enabled with an option?
I don't know, this is probably a BC Symfony 6.x could have but I see no reason to wait until then.
I'm open to suggestions to change this feature in order to make it safer for existing applications.

Do you have a concrete use case in mind where removing this limitation would be useful?

UsingPRE_SET_DATA event is the only way to add a form child and change its options based on given object state.

Let's suppose we have aform child we want to render asdisabledfalse when creating a new entity (letting the user to set its value) and render it asdisabletrue while editing (because the value cannot be changed but has to be shown).

There is no way to achieve that withoutPRE_SET_DATA on forms withinherit_data option.
The above is the actual use case that made me discover this Symfony Form limitation.

Any chance of moving this forward? It seems extremely counter-intuitive that some FormEvents are called on child forms and others aren't.

Any event allowing to modify the data is actually incompatible with inherit_data by design. So I'm not sure we should pursue this.

Why do you consider them incompatible? If this is by design it should be documented that some events trigger every time and others don't.

@Amunak see my comments on those lines that describe the problems.

@stof I understand. But if this is incompatible by design, wouldn't be better to throw an exception when you use*_SET_DATA,SUBMIT andinherit_data together?