bug#55645: src/print.c; print_object changes make it impossible to compare elisp code across versions

[Tom Gillespie]

> but admittedly, these changes are usually for more obscure
> objects than symbols

I was thinking the same. I realize that for many objects where
there is no guarantee of homoiconicity the prin1 representation
definitely changes all the time. However, I think that symbols
fall into a more homoiconic category (namely the category
of objects that can appear literally in code).

Some time between emacs 18 and xemacs/22 the reader
DID change with regard to periods in symbols. In 18 you had
to escape the period or the reader throws a syntax error.

Thus your point about there being a mismatch between read
behavior and prin1 representation is accurate.

That being said, I think this is be the first time in the history
of emacs that prin1 for symbols has changed, so having a
way to preserve the old behavior for things that depend on it
would be greatly appreciated.

> prin1?  Stable for 30 years?  Nope.  (But some objects have had a stable
> printed representation that long, I'm sure.)

Er, indeed, I was being overly general, I meant symbols specifically.
I went back and checked in emacs-18 and this is what I get:

(prin1-to-string '(a b\.c d))
"(a b\\.c d)"
(emacs-version)
"GNU Emacs 18.59.1 of Sat Jul 31 2021 on localhost (linux)"