> but why not let devs set `allow_duplicated_key: false` manually in contexts where it matters?

Because that wouldn't have prevented the issue I linked to.

Default settings are particularly important, because most of the gem's users have no idea that duplicated keys are even a concern.

JSON is used a lot to parse untrusted data, as such having strict and safe default is particularly valuable.

In your case the JSON documents are trusted, so I understand this change is of negative value for you, but I believe it has positive value overall when I account for all the users of the gem.

Additionally, even for the trusted configuration file or similar case, I believe most users would see it as valuable to not let duplicated keys unanswered, because duplicated keys are almost always a mistake and can be hard to track down.

e.g. a developer might have some `config.json` with:

    {
      "enabled": true,
      // many more keys,
      "enabled": false,
    }

And waste time figuring out why `JSON.parse(doc)["enabled"]` is `false` when they can see it's clearly `true` in their config.

So again, I understand you are/will be annoyed, because your use case isn't the majority one, but I'm trying to cater to lots of different users.

If going over your code to add the option is really too much churn for your low maintenance project, as I mention in the post, for such cases a totally OK solution is to monkey patch and move on:

    require "json"

    module JSONAllowDuplicateKey
      def parse(doc, options = nil)
        options = { allow_duplicate_key: true }.merge(options || {})
        super(doc, options)
      end
    end
    JSON.singleton_class.prepend(JSONAllowDuplicateKey)