The way we square this observation is to say that this isn't code that "depends on [the string's] value." That is, since the equivalence relation given by String.== considers Unicode canonicalization, the UTF-8 view of a string is a "non-value aspect," to borrow terminology from the same documentation you're quoting. (Indeed, offering different views of the same underlying storage is the way in which the stdlib provides access to different equivalence relations.)
It would be rather pedantic to insist that spelling such views as a computed property like string.utf8 is not allowed because it'd violate a semantic guarantee—in favor of, say, a more verbose and less fluent converting initializer String.UTF8View(string). Instead, the pragmatic approach is simply to regard utf8 as a "non-value aspect."
If I understand correctly that you are referring to substitutability with respect to all publicly exposed APIs whatsoever, rather than a flexible approach where some subset of the APIs can be deemed to be a "non-identity aspect," I think we actually don't want to commit to this, and particularly for String.
For example, consider the fair number of flags for "known ASCII," "known UTF-8," etc. It would be needlessly rigid to early-exit a fast-path comparison simply because one of these flags was pre-computed in one string but not another while they share the same underlying storage buffer. On the other hand, it would also be needlessly constricting to prohibit exposing APIs to access memoized properties simply because a type has implemented a useful isidentical method.