Thank you for writing this approach up @Chris_Lattner3, I think it looks really nice! I critiqued the global actor aspect of the design in a similar way. I know you had some questions about why that is useful. Maybe the examples I gave will demonstrate the utility.
I recall hearing of or reading about an actor system that had a similar notion. They called it "vats" - a vat could have many actors in it and it provided a serialization context for all of those actors, allowing code to take advantage of the knowledge that this context is shared. I haven't been able to dig up any references on this, but have used the idea in my own code and found it very useful.
On the topic of implicit vs explicit conformances, I think a significant drawback to implicit conformances is the site of the errors that will occur.
When the user passes a value of type T across contexts they will get an error about the missing conference of T. With implicit conformances, the actual reason for this error could be that some type U upon which T's conformance recursively depends is not provided. For example, maybe U is the NSMutableString from your example and a value of this type is several layers of types down, (i.e. T does not directly contain the string but one of the members of one of its members, etc... contains the string).
The actual logic error the programmer probably made is in the type that stores an NSMutableString may not be mentioned anywhere in the error. Even with a detailed understanding of how the type system machinery works, I can imagine myself taking a while to track down the actual problem.
If the compiler is smart enough to sort this out and consistently provide high quality error messages targeted at the programmer's likely misunderstanding of the code then maybe implicit conformances would work. But I think we should be careful about going down this path without having some experience.
This was my immediate thought on reading your proposal as well. It would be extremely exciting to see Swift understand types that have value semantics. The way I conceptualize this constraint is that heap allocated data is treated as copy on write.
I don't know how to specify all the details but I think one easy thing for the compiler to verify is that all public stored properties must have value semantics. With that rule in place, we only need to specify how lower level copy on write behavior is verified for code within the declaring module (or that the code is annotated as "trust me" similar to how we do with "unsafe").