I wrote a bit about why I'd oppose making this an error here SE-0364: Warning for Retroactive Conformances of External Types - #53 by rex-remind
Notable that I see this most often either when (a) using a test framework requires use of a trait (Rust's version of a protocol) and source and tests are in different modules or (b) using a library that requires a trait but the library's trait does not conform to common used types like uuid or does not conform one of its own types because the authors didn't find it necessary but devs may find it useful. I've even seen similar conflicts occur in code multiple teams own because of how they originally chose to organize crate dependencies on internal code even though we own the code (speaking of Rust still fyi). This generally results in adding a newtype which adds noise and harms grepability and consistency over re-waging the "right" dependency structure debates.
Question for the audience: does Swift's use of @testable help avoid (a) in any way?