Further workarounds I've found:
Synchronize properties to existing instances
Instead of replacing existing instances in the FlexRepeater, copy properties over to the existing instances. It's quite annoying to have to do this, but if you do it then the out parameters won't disappear. The basic approach was to step through the new array and the existing instances one by one and copying properties from the new one to the existing instances array. If the new array was longer then I'd append instances to the existing instances array. If the new array was shorter, then I'd remove instances from the existing instances array.
This is probably the workaround I'll use in the future.
Remove all instances, then replace the instances
Another workaround is to completely remove all the instances (e.g. assign flexrepeater.props.instances=[]) and then assign the new array values to instances. This workaround was mentioned in another issue.The downside to this approach is that any state held in input components, like text fields, will get wiped out. Also, there may be a brief moment where the view shows all the instances missing.
Force the output to change
When instances are replaced, the out parameters won't be propagated to the new instances unless the value changes. I found that even if I change the input properties, and the output parameter binding is re-evaluated, then the out parameter still won't be present on the flex repeater instance unless the output parameter changes. One such way to force a change is to have a constantly changing value, like a timestamp, be part of the output parameter. In such a case, a single output property could be an object like {"out":"real_out_value", "dummy":1681427822105}.
The out part of the object may never change, but the dummy value does, thus forcing the whole out parameter to change. I only add this workaround for completeness since it would be a very ugly and annoying way of ensuring out parameters are populated.