Just to provide some closure, I think I found the issue:
(via hexdump -C <filename>)
00000000 ef bb bf 73 61 6d 70 6c 65 2d 69 64 2c 61 62 73 |...sample-id,abs|
00000010 6f 6c 75 74 65 2d 66 69 6c 65 70 61 74 68 2c 64 |olute-filepath,d|
00000020 69 72 65 63 74 69 6f 6e 0d 0a 35 30 30 36 34 2c |irection..50064,|
First column is position, next two are the bytes as a single hex number and finally the ASCII value (if it is a visible character, otherwise it will be a dot)
Here we see that there are 3 bytes in front of the sample-id which starts the file. It appears you have an UTF-8 byte order mark, which is actually pretty rare, as UTF-8 doesn't have byte ordering issues like UTF-16 does.
Nonetheless, it was enough for QIIME 2 to get spooked and so when you used TextEdit, it likely stripped those bytes out making it work correctly again.
This is ultimately related to this issue:
(I just listed it as a good #hacktoberfest PR if anyone is interested in trying their hand at development, the fix is actually very straight-forward)