Depends what we mean by “break the system”. If the system fails to boot or a key component fails to start then you are right. But for what I meant - something worked correctly prior to the upgrade and no longer works correctly after the upgrade (because configuration has been lost) - then I wouldn’t bother to report it.
This is a well-known problem with ad hoc growth in nature of parameters and number of parameters. It is infeasible to test all possible combinations (exponential growth) but, worse still, there are subtle interactions between parameters where some combinations can’t make sense (i.e. not orthogonal).
If reporting anything to the package maintainer, it might be: improve the configuration file architecture so that the package maintainer’s version can be replaced on every upgrade and the user never modifies the package maintainer’s version but the user can apply parameter overrides via a separate config file.
It is still possible for an upgrade to break but it is more robust in the face of config-related software changes.
As I said: Usually the only way forward is to save all the versions and, after the upgrade, carefully study all the changes, and the documentation, to work out what is needed.
With great power comes great responsibility. 