I'm not sure that I am giving up on Emacs maintenance - the reference Noam supplied indicates this is a "well known" issue and somebody, has some intention, at some stage, to do something about it, but given the last update to referenced bug/email stream was 268 days ago, that intention may be on the back burner :-) 

Faking up a code snippet is not necessarily that easy - and, again, the problem described in 29220 sounds exactly like the issue I am having. I have already supplied the GitHub reference to my package and indicated the file that contains the functions that use/invoke the read/print processes. This is a working package, so, in my opinion, that satisfies that request :-) Using the package is not difficult, it is fully documented with its own user manual and the writing/reading process of the Lisp Objects is completely transparent to the user and happens automatically the first time the minor mode is invoked i.e. any maintainer investigating the issue shouldn't need to spend too much time getting to a point where they can debug the issue. The file(s) are written to the "user-emacs-directory".

regards
Peter



On Wed, Nov 21, 2018 at 2:46 PM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Peter Milliken <peter.milliken@gmail.com>
> Date: Wed, 21 Nov 2018 12:52:57 +1100
> Cc: 33441@debbugs.gnu.org, eggert@cs.ucla.edu
>
> I think perhaps you might want to put more information/warnings in section 19 of the Elisp manual because it
> is obviously not true anymore that you can simply Print/Read any arbitrary Lisp Object.
>
> I'm going to trap the error in my extension and just force reading/"compiling" from the original text file instead
> of reading from the intermediate file created by the print process. This will just cause a small delay to the user
> the first time that a set of language templates get loaded in an edit session - probably not a big deal. Certainly,
> it is better than telling people my extension is "broken" and won't work with 26.1 and onwards.

I'd urge you not to give up on Emacs maintenance so quickly, and
provide the reproducer requested by Paul.  Please give us a chance to
analyze the problem you are having and consider whether and how it
could or should be fixed.  Leaving the problems unfixed because we
failed to look into them is not a good paradigm in maintaining such a
flexible and powerful software package as Emacs is.

Thanks in advance.