When parseSettingsClass is executed, nothing prevents a rule having the same name as an already existing rule.

Since the behaviour of HashMap is to replace existing keys with the new ones, that makes (usually Carpet) rules to be overridden by the extension's rules, potentially causing undefined behaviour, since Carpet may apply a value from a Carpet rule into an extension's rule, or just users finding rules don't work as expected.

That should probably throw some exception (and therefore crash), although not sure which one.

Found due to #700.

Probably it's not that bad, preventing it would also probably disallow masking on purpose (is that a good thing?).

I've just discarded a PR for this (was extremely simple anyway), since I now don't consider this a problem. Feel free to close it. I'll do so in (at least) a week.