Bug#38708: eq vs eql in byte-compiled code

[Pip Cet]

Bug#38708 (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38708)
concerned a recent change to deduplicate floating point and bignum
constants in the bytecode constants vector (when compiling with or
without optimization). There was some discussion on the bugs list,
which I'll attempt to summarize here:

The previous behavior was that if

(defun f () (format "%S %S" 1.0 1.0))

was compiled, the result would have a constant vector with two
separate, distinguishable entries for 1.0.

The new behavior is that if the same function is compiled, a single
constant is generated and referenced twice.

My initial objection to the patch, and the reason I would prefer not
to see it installed on the Emacs 27 branch, is that the apparent
behavior of eq will change in ways that seem paradoxical at first.

For example, this code will produce t:

(defun my-eq (a b) (eq a b))
(defun f () (xor (eq 1.0 1.0) (my-eq 1.0 1.0)))
(byte-compile 'f)
(f)

The reason for this is that (eq 1.0 1.0) is optimized to nil before
the constants are deduplicated, but other function calls use the
deduplicated values.

All this is related to, but not the same as, the debate over whether
eq and eql should be equivalent or not. Making them equivalent would
avoid such apparently paradoxical behavior once and for all, but it
would probably incur a significant runtime cost.

Another option might be to deduplicate constants before optimizing
forms such as (eq 1.0 1.0). That would be more work, but would also
avoid the problem.

Any thoughts?