True, but not all non-UTF8 bytestrings contain 0xFF bytes, so it’s not very useful in practice.

Yes, I agree.

It's more common for programs that say they support UTF-8 to not really do so at all. It wasn't that long ago that "UTF-8" support was often just single byte, so it was little more than ASCII. Even now it's common for programs to choke on the optional BOM. Yes, it is redundant, congratulations. The spec still explicitly allows it. Three and four byte character support is still not the best, too.

	▲	flohofwoe an hour ago \| parent [-]
		> "UTF-8" support was often just single byte, so it was little more than ASCII "Single byte UTF-8" is ASCII. That's one of its most important properties. > Even now it's common for programs to choke on the optional BOM And they should... BOMs (and especially the hilarious UTF-8 BOM) are strictly a legacy Microsoft/Windows thing and should be abolished along with "extended" 8-bit ASCII encodings and UCS-2/UTF-16 (only UTF-32 makes sense, but should only be used at runtime to allow random access on UNICODE code points, but not for data exchange.