Also in reality making sure that your arrays can be replaced with lists means you can't store indexes into the array but instead you must store iterators, which sucks when you have to declare them (auto won't work in many contexts and typedef will expand into the ugly underlying type in many contexts), and sucks when you have to print them ("5" or "342" reads better than whatever garbage you'll have to resort to when printing out an iterator, and it persists better between program runs and across platforms, too.) So if I have an array/vector I'd rather not try to pretend that it's a "non-ordered collection" until I absolutely ought to use random access; I'd just treat it as an array/vector from the start.
So I guess what I'm trying to say is, not only is it not a bug but the attitude of people who write such non-bugs has many advantages.
(And BTW caring about performance is not the main point. A nice thing about your typical dynamic language is that there's not much gratuitous polymorphism. You get a few basic collection types and you use these and most code doesn't jump through hoops to be able to replace the standard collection type with some polymorphic replacement only satisfying a subset of the interface. So-called "type-rich" programming gets gnarly, I prefer "type-poor" on any day. Which isn't the main point, either, the main point is that things that work nicely in practice (like treating arrays as arrays) matter more to me than things that sound "right" from an abstract viewpoint (like being able to replace your collection types with other types.) And calling it a "bug" is, I guess it kinda bothers me and hence the wall of text...)