Ah, I saw you mention String's breadcrumbs as an example of a technique giving a feature that you'd want for all Collections. The breadcrumbs do not introduce a new type, they just accelerate certain APIs. We can do it for specific types we own (barring ABI constraints), but not for all Collections in general without introducing a new wrapper type.
It's still a linearly sized array. It would still perform an allocation (which can be costly in perf-critical code), do a linear pass over the entire Collection, and add O(n) space (even if the N is divided by, say 32). There is a real tradeoff here.
For String's UTF16View it made sense since the scan loop is very fast, orders of magnitude faster than doing character iteration. Scanning between breadcrumbs is likewise very fast; these can actually be done as a branch-free vectorized loop (yet to be implemented that way though). Random-access to UTF-16 in very perf-critical code is uncommon, i.e. it would likely be hidden behind Objective-C message sends and CF bridging logic anyways, so we have significant preexisting latency to hide behind (i.e. our constant-factors can be higher). Most such accesses are preceded by asking for the length in UTF-16, for which we need a linear scan anyways. And, the strings to which this applies are in the minority, most strings created are programmer/system strings and do not undergo the higher-level processing that wants random-access to UTF-16. Finally, String's storage representation is behind a resilience barrier and we had access to a lot of builtins to do tail-allocation and atomic compare-and-swaps.
Unfortunately, the introduce-a-new-wrapper-type approach wouldn't fix naive code (which is using underlying type directly), and any same-type solution needs to be done on the specific conformer.