What really bugs me about the redesign for Data is that it's completely thrown away NSData's support for toll-free bridging of discontiguous dispatch_data_t's (NSData forces contiguity when you access bytes but otherwise you can work with it discontiguously and even has a method to enumerate the discontiguous regions). This isn't documented, and the only hint is the fact that Data.regions is a CollectionOfOne<Data> (and the fact that enumerateBytes is deprecated, but the deprecation notice says to use regions). I had to dig through the implementation to discover that the moment you cast an NSData to a Data it access the bytes property, which linearizes the data.
I'm sure the implementation is a lot easier to deal with when it just has to manage a single byte buffer, but Data already has 4 different internal storage types already, surely it could have had a storage type that supported discontiguous regions.
I'm also annoyed that regions on NSData and DispatchData are arrays instead of lazy sequences. I get that the existing dispatch_data_t API only supports internal iteration of regions and not external iteration, but this is the Foundation team, they could have added the requisite dispatch_data_t APIs to the framework for external iteration. Ultimately, the point is I shouldn't have to allocate just to read discontiguous data.
And on a related note, it's also now impossible to cast a DispatchData to an NSData, even though that's supposed to work. I can write something like unsafeDowncast(data as AnyObject, to: NSData.self) but this is gross and unsafe.
All of this really should have gone through some kind of review process visible to the community. Doesn't even necessarily have to be the full swift-evolution process, it could just be "Here's a document in proposal format explaining the changes we're making, there's no review process, unless someone has a really serious objection we haven't considered".