This would be a good time to remind people of how we arrived at the Swift API Guidelines, particularly the first naming guideline, “Include all the words needed to avoid ambiguity for a person reading code where the name is used.” Following that principle leads directly to many of the naming choices in the standard library, some of which Ben is complaining about here.
The naming guidelines are a product of work from people from across the spectrum of subjective viewpoints, from those inclined toward minimal names like those in C++, to those steeped in the rather verbose tradition of Cocoa. Given that diversity, it's remarkable that we eventually achieved a consensus that everybody involved could buy into.
At the time, the tradition of Objective-C naming patterns was so heavily ingrained in the culture of the participants, that had we not de-emphasized subjective criteria like “mouth feel,” we would have ended up with standard library APIs in Swift that most of us would regard today as wildly inappropriate for Swift. Code that read simply as a.contains(b) could elicit a strong “yuck” reaction from an Objective-C programmer who expected each parameter to be introduced with a noun describing its type. Furthermore, emphasizing “mouth feel” over disambiguation can be harmful: we found examples of several Objective-C API that would “ring nicely in the ear” for someone steeped in that tradition, but in practice resulted in misleading code.
It is perfectly appropriate to spend a few words, and even risk disrupting a reader's sense of pronounceable code, to avoid an easily made misinterpretation at the use site of an API. That has always been a principle of naming in Swift's standard library, and discarding it now would not only create inconsistency, it would undermine one of the library's core design principles.
I can hardly think of a case that warrants this sort of treatment more than one where a reader will see a Range being inserted into an instance of RangeSet, which is not actually modeling a set of ranges.