This surely is a bug. The first should write 'te\\st', no? Is this some edit work? Note that I’ve added Discourse code block markers (```) around the code.
The second is surely wrong though and does reproduce. It relates to commit cbe691f8af61ccaf466147868a316b96c110fedb. That is because atom_to_term/2 calls PL_write_term(), the C api to the writer with quoted, but without char escapes. This seems fixed in the wrong place. In fact, all over the place PL_WRT_QUOTED is used, but without character escapes enabled, probably including a lot of external packages.
Another complication is that the character_escapes Prolog flag is module local, so we could handle mixed code with and without character escapes in the same program. write/1 and friends use the setting from the user module.
This makes the whole thing a bit of a mess May I ask why you use character_escapes(false)?
Anyway, this needs some thought. I’m tempted to change PL_write_term() to accept, next to PL_WRT_CHARESCAPES a PL_WRT_NO_CHARESCAPES and, if none of these is present use the flag in the user module. Practically, that would imply that many conversions to quotes text start escaping as quoted write does. As is, only the quote and \ are escaped, which does allow to read the term back unambiguously.
Alternatively we could have three modes for PL_write_term(): unquoted, quoted with normal escaping and quoted with minimal escaping (only the quote and \\). Three modes would introduce fewer incompatibilities, but otherwise seems wrong. Note that this mostly affects the C interface, but for example also term_to_atom/2 which directly using the C interface for converting a term to a string (atom).
Thoughts are welcome. Surely first needs some consideration.
Hm, somehow Discourse messed up my message.
The problem occurred after we had ported an older application from (good old) 5.9.7 to a new SWI-Prolog version.
Rewriting the app which is using portray/1 and other tricks is unfortunately not an option.
Here a screenshot with old and new behaviour:
I have created a PR following the proposal described before. If anyone sees problems with this, please comment on the PR (or here).
Unfortunately we can probably not fix the stable series as I see no sensible way to fix the bug and remain compatible while I think the impact of this 13 year old bug is smaller than the incompatibility. While I do not expect many problems with these changes it is not unlikely that it will affect some applications