What am I missing here?
Now deprecated dynamicType was capitalized, but associatedtype and typealias are not. I would like to see this rectified in a future Swift. Perhaps someone here can point me toward a pre-existing discussion on this topic which would make me grateful to read.
In that proposal, one of the reasons (perhaps that's too strong a word, but one of the points against it) was that its casing was one of very few exceptions among keywords in the language:
dynamicTyperemains an exception to Swift's lowercased keywords rule. This change eliminates a special case that's out of step with Swift's new standards.
Having multi-word reserved words like declaration types (associatedtype, typealias) and modifiers (fileprivate) be all lowercase helps to distinguish them from identifiers, where the guidance is to use lowerCamelCasing. IMO, adding capital letters to those keywords would harm readability in that sense.
Thanks, I overlooked that bullet point. The casing employed in dynamicType was much more pleasant in my opinion. Smooshing two distinct words together seems utterly disrespectful to written English.
I really scratch my head, but I think we had already a similar discussion on the forums. IIRC @Erica_Sadun proposed the alignment of willSet and didSet once, which are also reserved keywords but do not follow the same rules.
Edit: Ah here it is: https://github.com/apple/swift-evolution/blob/master/proposals/0098-didset-capitalization.md
Rationale:
Hello Swift Community,
The review of SE-0098: "Lowercase didSet and willSet for more consistent keyword casing" ran from May 24…30, 2016. The proposal is rejected for Swift 3.
The feedback on the proposal from both the core team and the community was that these should remain camel cased, particularly given that they may become user-definable aspect names in a future release.
Many thanks to Erica Sadun for driving this discussion and writing the proposal. This was an important topic for the community and core team to re-evalute.
-Chris Lattner
Review Manager
Many things in Swift don't follow written English. struct is not an English word. The semantics of "or" are not those of written English, where it usually means xor. You can't write cond1 and cond2 unlike English (or Python). We say "sort a list" but in Swift it would be written as x.sort(), not sort(x).
Many of these points above have precedent in other programming languages, so it makes sense that Swift follows them, even though they flout the rules of English. Having some Camel case keywords would again break from what is typical in a programming language.
Also, on a lighter note, it is not uncommon to smoosh words together to form new words in English. That's what portmanteaus (e.g. smog) and compounds words (e.g. footpath) are about 
.
Your other examples are good, but x.sort() translates to "x, sort", which is short for "x, sort yourself". http://www.catterwaul.com/computers-are-programmed-with-sentences/
I haven't felt convinced by arguments against associatedType and typeAlias.
The burden here only goes the other way, i.e. you need to somehow convince people with arguments for them, because it would be a source-breaking change (or, at least, introduce a pointless redundancy).
To draw a finer point to my argument, typically we would define the compound word in our English language first. However, at the moment documentation still refers to typealias as "type alias."
I do agree with your point that precedence in programming languages is more relevant here.
N.b. Erica Sadun's proposal is admirable if not only for the case of establishing more consistency, which ought to be a primary goal.