Either it's a EU thing or I'm missing something crucial here. I'm especially confused as to the listing of the ampersand (&) as a viable character... also I just did a bit of testing specifically with "\" and there didn't seem to be any problems.
"\" in addition to certain letters behind them can transform into new symbols. \n turns into a newline. That can mess up the string and you might not be able to retrieve it correctly - at the very least it'd make displaying that string messy and bugged.
And the ampersand can be used in strings, so why not have it as a valid character?
Whenever I save a string containing "&" it becomes "&"
"<" and ">" save as "<" and ">" respectively
I'm not familiar with XML but it's obviously some methodology of tracking what XML considers special characters, that's why I figure "&" of all characters is out of the question. Again my only answer for this discrepancy is some regional difference, or else some trick I'm not aware of.
However, this special way of storing them also means they take up more space. Having a few of the characters take up 4 instead of 1 invalidates the entire idea of having a compression in the first place.
I haven't done any math on that but I believe the compression is actually better by excluding these and going on with a slightly smaller base.
I did further testing with "\" making a point to try and produce line breaks but had no problems. I also took a look at a few tooltips and noticed that line breaks and every other formatting was contained within <>... so "\" still appears to be completely harmless, even if you convert the string to text it reads it literally without the <>
I took my information directly from the starcode thread, without testing this myself. I tried it out now, and you appear to be correct in every way. So I guess, Starcode needs to get rid of > and & and may add \