@Michał Sikora: Racja, zbyt szybko przeglądałem i przeoczyłem. Jednak te operacje zawsze budują nową kolekcję od zera, a więc np dodanie elementu do TreeMapy ma złożoność obliczeniową O(n lg n) i pamięciową O(n) zamiast złożoności O(lg n) obliczeniowej i pamięciowej w przypadku kolekcji ze structural sharing.
Oprócz zawyżonych złożoności z powodu braku structural sharing mamy niepewność co tak naprawę dostaliśmy - widok tylko do odczytu może oznaczać, że mamy do czynienia z niemutowalną kolekcją, ale równie dobrze ta kolekcja może być mutowalna i co gorsze mutowana gdzieś indziej w trakcie gdy my z niej korzystamy. Dokumentacja Kotlina podaje:
Unlike many languages, Kotlin distinguishes between mutable and immutable collections (lists, sets, maps, etc). Precise control over exactly when collections can be edited is useful for eliminating bugs, and for designing good APIs.
It is important to understand up front the difference between a read-only view of a mutable collection, and an actually immutable collection. Both are easy to create, but the type system doesn't express the difference, so keeping track of that (if it's relevant) is up to you.
(...)
Note that the readOnlyView variable (ed: MutableList zrzutowana na List) points to the same list and changes as the underlying list changes. If the only references that exist to a list are of the read-only variety, we can consider the collection fully immutable.
W Ruście też nie ma structural sharing, ale tam przynajmniej kompilator pilnuje by nie mieszać referencji pozwalających na mutowanie z referencjami tylko do odczytu. Mając referencję tylko do odczytu w Ruście można być pewnym, że kolekcja w danym miejscu będzie zachowywać się jak niemutowalna.