Issue #20307 has been updated by byroot (Jean Boussier). I don't understand the bug report nor the patch. If you make a frozen copy of the provided key, you change the key. e.g. ``` cache = {}.compare_by_indentity key = Random.bytes(5) cache[key] = 1 p cache[key] ``` I'd expect `cache[key]` to return `1`, with what I understand of your patch, it wouldn't anymore. Mutable hash keys aren't a new thing, it's only that regular hash have this special behavior for strings to keep a frozen copy of the string key, but they don't do that for any other type. I don't see why identity hashes would need to copy this behavior. ---------------------------------------- Bug #20307: `Hash#update` from compare_by_identity hash can have unfrozen string keys https://bugs.ruby-lang.org/issues/20307#change-107115 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- I don't think this behavior is expected. ```ruby i = Hash.new.compare_by_identity k = "a" i[k] = 0 h = {}.update(i) p h.compare_by_identity? # => false p h["a"] # => 0 k.upcase! # `k` is still in `h`. p h.keys.include?(k) # => true # but not found. p((h.fetch(k) rescue $!)) # => #<KeyError: key not found: "A"> h["A"] = 1 p h # => {"A"=>0, "A"=>1} ``` I expect `h` to still have `"a"=>0` entry. -- https://bugs.ruby-lang.org/