As I see it, there are source-level and ABI-level commitments we'd be making with these special case conformances. At the source level, as it stands today, nobody can make structural types conform to any protocols. If we lift this restriction later, then it seems inevitable that we would provide conformances for tuple Equatable, Hashable, and Comparable in the standard library at the same time. This would in turn prevent any other modules from declaring overlapping Equatable, Hashable, or Comparable conformances on tuples according to our current rules. If we accept the builtin conformances, we end up in an intermediate position where the conformances are provided effectively by the standard library, but nobody else can declare any conformances at all, which seems like a situation that will be source-compatible with the future world where conformances are generalized.
On the ABI side of things, code that instantiates generic definitions using these conformances will need to be able to reference symbols for the witness table template and conformance descriptor that identify the conformance. These will be special case data structures if the conformances are built-in, but equivalent data structures would exist for the conformances declared by the standard library. To maintain ABI compatibility, we may need to continue exporting the special-case symbol names from the standard library, but chances are good that these could become aliases for the more general data structures that would be generated by the compiler for a library-defined conformance. (This would mean that people looking at the data structure of the builtin conformance descriptor for reflection purposes would need to be aware that the exact nature of that descriptor may change in a future runtime.)
Based on this, I think the long-term impact of these conformances should relatively small and manageable.