I started digging into it, a eventually worked out that some system at the start of the chain was using the ASCII US and RS characters to separate the notes! Each note would have the format of
timestamp␟username␟note␞timestamp␟username␟note
I ended up just searching and splitting on those messy characters to recover the structured format of the notes. (They were all dumped into a single field in the SOAP record. I hate SOAP enough as it is, but was amazed how our systems managed to ruin it even more :)
It's useful when there's a chance of power loss or program crash during logging and it's important to recover all the written records.
With conventional logging that terminates each line with LF, if the write is interrupted, after the program restarts the next logged line is merged with the previous part-line. The result is the first line of each log file after each restart is junk and fails to match whatever patterns are scanned for later.
When each line begins with RS and ends with LF, lines that are written whole are always found later.
That can't be done; the concept of a "record separator" character already assumes that there is a value that can't occur within the data. If you play along with that, you're not making good use of anything.
You're better off using commas and being forced to constantly confront the fact that tons of data contains commas than using a byte value that hides the problem slightly better than commas do.
But, modern text editors almost universally can't even manage to provide a coherent means of editing boldface text (cursors always get stuck on the wrong side of a hidden tag). So I doubt such a feature would have been well supported, even had it existed at all.
However that requires a smarter program to display the data the intended way. CSV files, and their cousin of sorts TSV files, can often be sufficiently read both raw as well as on line printers.