Do we still need both infer_ac_model and infer_ac_model_multi? Maybe not.

The alternative is something like the nested if statements of PVSystem.get_ac. We need some way of raising a ValueError if num_arrays > 1 and the parameters are not consistent with pvwatts or sandia (essentially what we have now in ModelChain). Equivalently, for now, we could raise a ValueError if num_arrays > 1 and the parameters are consistent with adr (essentially what we have now in PVSystem.get_ac). This behavior is tested in test_ModelChain_invalid_inverter_params_arrays. I have a slight preference to leave it alone, but I'll change it if you prefer it more like PVSystem.get_ac.

We need some way of raising a ValueError if num_arrays > 1 and the parameters are not consistent with pvwatts or sandia (essentially what we have now in ModelChain).

Agree. It might make more sense to do the validation in PVSystem.get_ac so that it catches both ModelChain and PVSystem users.

The _infer methods are only used when the inverter model isn't named, and the parameters for either _multi inverter model are the same as for the single MPPT version. That's why I don't see a need to keep both _infer methods since the ModelChain methods are aligned with the three model names rather than with the five inverter functions.

Assuming you agree with either of these points, I'm OK deferring to later work.

One more trade off here... The validation in the infer method helps avoid errors in PVSystem.get_ac during run_model. Traditionally ModelChain.run_model is nearly guaranteed to run if ModelChain can infer all methods at construction. Of course, as you point out, it only works if the user does not pass ac_model.

I'm generally -1 on input validation within pvlib so I'm ok with changing this in the long run.

Raise ValueError in _infer_ac_model when parameters indicate 'adr' and num_arrays > 1. Otherwise get_ac should be fine.