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/