Yeah, people should stop talking about sanitation in relation to SQL, because that is how we end up with data like "OConnor". The two correct solutions are escaping and parametrization/prepared statements (i.e. sending the parameters out of band).
Another example: A "transformation" that's a "sanitation" but not "escaping" would be replacing all occurrences of "<" with "<" (among others!). It surely doesn't add escape characters (e.g. \), but instead replaces the problematic substring with a replacement string that makes the string safe to display on a website. Of course you'll want to replace user-supplied "<" with "&lt;".
(btw, thanks for that it's "sanitation" and not "sanitization" ^^).
Now a Google search finds instances where sanitization/sanitation also includes techniques beyond filtering: https://www.webopedia.com/definitions/input-sanitization/ https://hack.technoherder.com/input-sanitization/ https://developer.wordpress.org/plugins/security/securing-in... https://stackoverflow.com/questions/129677/how-can-i-sanitiz...
But there are also results where it isn't really clear, or where the only sanitation technique considered is filtering. So I'd say "yeah, it's unclear and poorly defined".
Buuuuut: I still like my definition more, as I have a word for "all techniques that aim to make an input safe for processing" (sanitation/sanitization) while I can still refer to "destructive elimination of substrings" as just "filtering", which is a again different from outright "rejection of input" by using an "allow list" or "deny list". :P
I agree that splitting data and code is the way to go, if that's an option. But I didn't talk about that in the post you're answering to, so I'll ignore that ;-)