I would be -1 for this. The integer subscripting into String has been intentionally rejected multiple times for a reason. This just feels like a more general approach to the same thing (and has been stated as one of the most common use cases for this).
Swift indexes exist for a reason and integer offsets on a basic collection were intentionally left out of the language. I feel like proposals like this are just people swimming against the current. There are good reasons that things like C for loops have been removed from the language and integer offsets into collections are not permitted unless a very specific set of criteria are met.
While this is slightly less likely to be abused because it is a named subscript and therefore not the default, I feel like it would only be a matter of time until everyone is reaching for this instead of the intended tool, especially if all beginners are just taught to use this because it's easier and familiar. Rather than fighting the language's principles to tailor it for beginners, beginners should be taught the reasons behind the language principles. Rather than suggesting people avoid indexes altogether we should help people to embrace them.
Swift claims to be performant. The goal is to run as fast as C code when optimized and things like this would make that impossible and your average user would probably have no idea why their code is running 4x slower than an equivalent piece of C code.
Also, the fact that this would also affect both
Dictionary cannot lightly be tossed aside. If an API has an effect on two core objects of the standard library then that effect must be taken into consideration. This would also impact any existing code which conforms to collection, some of which may also not make sense to have an integer offset (I can think of at least one collection in some of my own pet projects where it would not make sense to have an integer offset).
I view this as a purely sugar proposal which can be trivially implemented if truly desired. It results in strange functionality being permitted on multiple core types, not to mention the effect it would have on 3rd party code for which it may or may not be desirable.