⎕ucs 10 uglies still not fixed in ]link for character data

[bernecky]

I conflated two distinct issues into one. Mea culpa. Here is one of them:

And then, as they say in Russia, it got worse:
I am trying to use ]link to keep things under git. Here is
what a similar file looks like under bash, when maintained
by ]link:

cat FRGquotequad.apla 
('% Code fragment for quote-quad input and probably others',(⎕UCS 10 10),'%Fragment qdd XX1 X X C .',(⎕UCS 10),'inline char[.] $FNAME()',(⎕UCS 10),'{ /* Quote-quad input */',(⎕UCS 10),'  arbitrarylimit = 100000;',(⎕UCS 10),'  z = drop([-1], tochar(scanl(arbitrarylimit)));',(⎕UCS 10),'  return( z);',(⎕UCS 10),'}',(⎕UCS 10 10))

The real data looks like this:

apex@boa:~/apexgit/Source/Root/sac/fragments$ cat quotequad.frg 
% Code fragment for quote-quad input and probably others
%Fragment qdd XX1 X X C .
inline char[.] $FNAME()
{ /* Quote-quad input */
  arbitrarylimit = 100000;
  z = drop([-1], tochar(scanl(arbitrarylimit)));
  return( z);
}

This is on a linux box, running the latest ]link, from the Ides of March: e626cb7
The treatment of LF (NL) makes it effectively impossible to use a normal text editor, or even
a grep that wants to know about NL, to operate on files resulting from ]link. They are also ugly as sin.
Uglier, actually.