let works differently for structs and classes which if fine and clear as it is the main difference between them. Dictionaries are like structs truly immutable when declared with let. Arrays declared with let on the other hand have a complicated partial mutability and copy on write combination that depends on whether the operation changes their length.
I've got another post that is a work in progress that shows some of the behaviour I find odd. When I've finished it I'll add it to the blog properly but I don't mind people seeing and commenting on it as long as they know it is a WIP:
Currently I don't find it a big issue, however the language is still not final, maybe this can still change.
I imagine Apple might still act on some initial feedback before Swift 1.0 gets released.
I imagine the point is to have a low level type describing an area of contiguous mutable memory, rather than expecting people to use arrays everywhere. Not that I know anything about Swift of course.
Array when mutable acts like a list: items are indexed by an integer, and you can replace, add, and remove items.
Array, when immutable acts like an area of contiguous memory: items are indexed by an integer, and you can replace items.
Dictionary, when mutable, acts like a map: items are indeed by key, and you can replace, add, and remove items.
Dictionary, when immutable, acts like a read-only map: items are indexed by key. You cannot add, remove or even replace items.
That is inconsistent. I think they would be better of adding List as a third container type, and changing Array to a fixed size (at creation time) container. Immutable Lists and immutable Arrays would behave exactly the same, but I don't see that as a problem.
On top of that, they chose to make Arrays and Lists value types, (prematurely?) optimized Arrays (but not Dictionaries) to copy-on-write their data, and decided to make that manual copy-on-write (to ensure that an Array is yours and only yours, you have to call unshare on it)
My disclaimer is that I only read the ePub that Apple provided, and somewhat partly so.
It helps to think about Swift's let as C++ const and how it maps to library data types, not as ML's let.
Given that the target audience are Objective-C, C and C++ developers, I don't think it is too bad of an option.