Liberal vs strict is a false dichotomy. The third solution is to accept all possible inputs, but in a specified way.
Instead of taking draconian XML approach you can solve the problem by taking HTML5 approach and make error handling as interoperable as handling of correct input. In case of STEP files you could require all implementations to clear the 8th bit (or drop or clamp bytes out of range — whatever as long as it's specified and mandatory).
Trying to do something with 8-bit characters -- whether skipping them, indicating an illegal character in the string, or trying to guess what was really meant -- cannot make that situation any worse.
In the case of ie, ie decoded one way and forum software might decode a different way. So the forum software says the string is safe for the browser (according to its decoding rules) but then the browser applies different rules and gets a bad string.
You may not be seeing the danger because you implicitly think a step file from unsafe sources is always unsafe. But imagine if you had a safe file detector program, except it applied different rules than the program you're actually going to open the file with.
When an implementation saves this file, it normalizes that other encoding to use an ASCII single quote, then proceeds to write out the rest of the string. This isn't caught inside the implementation, because the encoding library only normalizes when writing. When it reads the data in, it still just represented it as bytes, and there was no ASCII single quote byte until the end of the dangerous string.
So, yes, it's possible that even something as simple as "string encoding" could be used to implement an attack.
And again, if you're worried that there may be an attack vector, change high-bit-set characters to "[Illegal character value N]". Though it might be more merciful to assume they just wanted ISO-8859-1 characters and substitute the appropriate control code.
For instance, the STEP file standard very clearly states that all input files must be 7-bit ASCII. Many of the programs that generate these files (including earlier versions of my own) paid no attention to this and wrote out 8-bit values in strings if the user requested it. Clearly this behavior is wrong. (The principle agrees: "Be conservative in what you do.")
However, rejecting an entire CAD file merely because the text strings in it used an illegal encoding is downright silly. It in no way can change the meaning of the geometry of the file. There is no hidden vector in there for malicious attacks. It makes perfect sense to accept illegal files like this and do your best to make them work, even if it might not get quite the same text strings the user intended.
I think jbert's point about being conservative in what you do in all respects is a strong one. Taking that into account suggests that maybe carefully marking the illegal character as such in the string might well be worthwhile, and is definitely more appropriate than trying to guess what 8-bit character standard was intended.