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

[Tom Gillespie]

> Like I've said before, we (the Emacs maintainers) would not guarantee
> that Emacs' `prin1' will remain the same.  If you want to create a
> package that does printing in a different way, you're free to do so, of
> course -- we have the `cl-prin1' framework in Emacs already, and you can
> use that to print things any way you want

Unfortunately none of these work for my use case because cl-prin1
is not available before emacs 26 and it differs too much from prin1
to be useful without requiring additional code. I have to fit all the code
under 3000 chars because it is in an eval local variable and the changes
for cl-prin1 are too extensive.

I'm not 100% sure how to use cl-prin1 but as far as I can tell defining
new cl-print-object methods (e.g. for symbol) is highly invasive and
makes changes to the entirety of the user's runtime.

Would a patch that leveraged cl-prin1 to create a function that matches
the old behavior of prin1 be more viable?

Without that my only solution is to restrict symbol names so that they
do not include . and ? by raising an error if they are detected, and hoping
that prin1 doesn't undergo another change in the future in the readable
subset of objects.