This is really interesting, it's a character encoding issue in the result file.
The polargraphcontroller outputs and reads text files with UTF-8 character encoding, but the optimiser script has outputted text files with UCS-2 LE BOM character encoding. I admit I hadn't ever seen any examples of this encoding before.
To find this out, I loaded map2.txt into polargraphcontroller and saw the queue looked like this - with all the little empty boxes being where the polargraphcontroller has interpretted multi-byte character values as multiple separate characters!
To fix this, I simply changed the encoding to be UTF-8 and it loaded ok. I loaded the file into notepad++ and then clicked Encoding-> convert to UTF-8. It also brings the file size down to 1.4MB.
I imagine there is a setting somewhere in your OS or your installation of python that sets the default text file format to be UCS-2 LE BOM, and that's why it's happening without you asking for it.
However, there's something else obviously odd that's going on here if these two txt files are of the same artwork (I can't really tell because my machine is a different size so the actual preview is distorted). The artwork in the first file (test_1.txt) is full of line instructions targetting the 1000-1800 space. That means the instructions are usually telling the polargraph cables to be between 1000 and 1800 steps in length. That might be up at the top of the machine.
The second file (map2.txt) has completely different numbers in it - all from the 2000 to 7000 space! This indicates a slightly deeper problem than just character encoding.
Is there any chance these files are of different pieces of artwork?