To a degree, Rust does this. The standard string type is always guaranteed to be valid UTF-8. Then there's a string type for the OS native format and a string type for what constitutes a valid path on the file system. Of course, arrays of bytes also exist and so does a type for a null-terminated "CString". Converting between them requires runtime checks (unless you invoke unsafe code and promise you know better than the compiler).

It's cumbersome at times, but a perfectly reasonable tradeoff in my opinion. Some libraries add other string types when they're needed to interact with a system. For example, the windows crate has wide strings.

This is a good idea I believe. While I agree it would be convenient to have it in the standard library of more languages, it can be implemented in strongly typed languages, using something like Newtype in haskell. In Typescript, for example, it could be:

  type SanitizedString = string

And somewhere you have a function getSanitizedString and if you don't call that the type system will complain.

Same could be done to represent a distance in Km or miles:

  type DistanceKm = number
  type DistanceMiles = number

And then functions can explicitly use any of them or only some (we could define some function multiplying them to allow 2 arguments only if they are the same type).

When Python did that to separate raw bytes and proper Unicode, people pointed this out as a reason they don't want to use the language any more.

Sounds like Python wasn't right for those people in the first place. Abstracting away the internal data format is typical of Python.

There was a research C compiler, maybe related to the meta-compilation effort that became Coverity, that did something like this. It let you attach arbitrary attributes to a variable and then enforce invariants regarding those attributes. The one that caught my eye was tagging checked vs. unchecked user input, so that using such input before checking (or sanitizing) would become a type error. It's a shame that the idea didn't catch on more.