I think it's also worth noting that I routinely see this cited as an example of problematic behavior by the compiler and something that we might want to consider fixing at the next major version bump. 
Well, it's a bit broader than this, since trivial compositions of non-value-semantic types which are still Sendable would also conform to Sendable implicitly, but I think this is a reasonable position and I'm willing to accept that I may just be on the losing side of general consensus here. 
I do want to push back on the following point, though:
Across module boundaries, it's impossible in the general case for clients to determine whether a type is thread-safe by construction, since arbitrary implementation details may be hidden in internal/private members. Any semantic change that a library author makes could break clients who were relying on undocumented/buggy behavior, and without first-class concurrency features, library authors can only really "promise" thread safety by writing a note in the type docs.
But this proposal introduces a new way to promise thread safety which can be enforced by the compiler, and automatically applying that to public types when the compiler can verify its validity will constrain library authors in potentially unexpected ways, with no great way forward for them other than to break source compatibility for clients. OTOH, for an author who forgets to add a conformance which is not generated implicitly, the solution is just to add the conformance (possibly with an availability annotation).
Of course, I'm not someone responsible for maintaining any large libraries which might benefit from or be harmed by the implicit conformance, so these concerns are quite hypothetical. But I am worried about ending up in a future where it's a routine practice for library authors to have a blanket declaration like "do not rely on Sendable conformance for any types which do not declare it specifically, as they may become un-Sendable in the future."