I hinted at what this additional semantic is in my post above (bolding is my new emphasis):
Essentially we expect isIdentical to form an equivalence relation whose equivalence classes are smaller and subsets of the equivalence classes of ==. This property is not satisfied for Int (all equivalence classes contain just a single value) so defining Int.isIdentical doesn’t buy us anything new. But it is satisfied on String because “café”’s equivalence classes under == are the two standard representations of the word ("caf\u{e9}" and "cafe\u{301}") along with all storage representations of these strings. And so in this case String.isIdentical is helpful because it greatly reduces the size of the equivalence classes.
And not to open up a can of worms, but the Swift docs on Equatable makes a big statement that is not really true:
Equality implies substitutability—any two instances that compare equally can be used interchangeably in any code that depends on their values.
An easy counterexample to this is the following:
func f(_ string: String) -> Int {
string.utf8.count
}
With this function, f("caf\u{e9}") != f("cafe\u{301}") yet "caf\u{e9}" == "cafe\u{301}", contradicting "substitutability" defined above. What the docs calls "substitutability" is also known as "well-defined" functions, and while related to equivalence relations, it certainly isn't implied by having one.
However, isIdentical should satisfy this substitutability property, so it is another property that could be added to the docs to describe its semantics.