This is false. You can implement methods in the indexable interface without implementing any in the iterable interface, and vice versa. An indexable can also lack firstindex and lastindex because it has no semantic beginning and end, e.g. LinearAlgebra.I. Obviously without a start, I is not iterable. Immutable indexables like I also lack setindex!. The AbstractArray interface specifically includes both indexing and iteration; that doesn’t imply indexing and iteration are intertwined in general.
This is also somewhat false, there is a fallback last(coll) method based on lastindex and a fallback last(itr, n::Integer) method based on iteration. More specific methods of either arity can be defined however you like. For example, the non-indexable and infinite iterator from Iterators.cycle implements last(it::Cycle) to fall back to last of the wrapped instance.
An aside, last(itr, n::Integer) depends on Iterators.reverse, which isn’t in the leading table of methods but is mentioned at the very end of the iteration interface docs. That’ll be the faster way to do last for iterables than iterating from the start, and evidently from Cycle does not require a finite length.
Go eschews method overloading and multimethods to allow its type system and dispatching to even work. This is a fundamental design tradeoff.
I have no earthly clue what this could mean. The reflection I mentioned has nothing to do with how I would dispatch my methods, it would, for example, check last(::MyType) and tell me to implement lastindex(::MyType), or check last(::MyType(), ::Int) and tell me to implement Iterators.reverse(::MyType). Ideally it’d save me the trouble of looking up interface documentation and source code.