I think the ideal solution here would be, if the character set is mutable, to have the act of bridging actually replace the inner storage with the copied immutable NSCharacterSet, as bridged character sets are unlikely to be subsequently mutated and mutable character sets have a performance penalty (see SR-3006). But Swift has no precedent for a bridging operation actually mutating the source value.

Barring that, it might be worth actually considering the idea of changing CharacterSet to be immutable and to have a separate type as a mutable character set. This way CharacterSet can be guaranteed to be backed by an NSCharacterSet, and the separate type can be non-bridgeable and thus sidestep the issue of exposing its NSMutableCharacterSet. This separate type could be something like a CharacterSetBuilder that uses a builder pattern API to construct a CharacterSet (the idea being that character sets are generally not mutated after they're constructed, any such changes after the fact are usually done with the immutable methods that return new character sets). For backwards compatibility reasons we can keep the mutating methods on CharacterSet but deprecate them, and then fix CharacterSet's Obj-C bridging to copy the inner NSMutableCharacterSet if mutable. And finally, we can ensure that all non-deprecated CharacterSet methods result in having an immutable NSCharacterSet as the backing storage (such as the methods that return a brand new character set; I haven't checked what they do today, but hopefully the backing storage for the returned character set is already immutable).

I'm not aware of any precedent for the Swift stdlib / SDK overlay to provide a builder pattern like this, but this approach very neatly ensures that anyone constructing a CharacterSet will end up with an immutable backing storage, which is important for performance reasons.

I just checked and it turns out the CharacterSet methods that return new sets (e.g. union) actually return sets backed by NSMutableCharacterSet.

cc @millenomi