Brought about because of ICE-9146, there is the issue where EditableValueHolders do not state save their submitted values, so after a lifecycle that was invalid, if the next lifecycle is due to an ajax call that only executes certain component(s) but renders all or at least ones that were not executed, then those unexecuted and rendered components will glitch where they will have lost their submitted values, and did not decode to pickup again their submitted values, so they will then render their previous values.

Ideally, those unexecuting EditableValueHolders could just decode their submitted values, and do no further processing, so that they would render correctly.

Alternatively, much like the FacesMessagePhaseListener (ICE-5750, ICE-6820, ICE-7137), we could propagate the submitted values forward, and set them before the ApplyRequestValues phase, so that any newly submitted values would then take over. They could explicitly be saved at the end of the previous lifecycle and restored in the subsequent lifecycle, and saved in flash scope inbetween. Potentially the RequestParameterMap could simply be used, but there are cases like checkbox components, where the raw string is mutated before being set into the submitted value. There could be an algorithm that only saves into flash the objects that are not the exact strings found in the previous RequestParameterMap, so that the saved state is as small as possible, and then the restoration would comes from both the new RequestParameterMap and the saved submitted values, with the saved submitted values taking precedence.