Why such focus/fuss on the implementation data structure?
They're both just maps from a key to a value, let "the compiler" figure out how best to store them. (If you are mapping on top of a 'foreign' object that is a completely different thing, making it look the same may or may not be confusing)
It's not just implementation, but also semantics.
A vector is an ordered, O(1) access/modification, structure.
A hashtable is (usually) a non-ordered, amortized O(1) access/modification structure. The implementation details don't matter, but these characteristics do, since they are important to reason about your algorithms.
(Edit: You may think you can treat integer-indexed hashtables as vectors. Suppose you have a 'map->list' operation that applies fn to given aggregate type and returns the list of results. The semantics of (map->list fn a-list a-vector) is obvious. (map->list fn a-list a-hashtable) is not so obvious, and eventually you'll end up different map functions for different purpose. So it's a trade off---fewer data types and more specialized functions, or more data types and fewer
generic functions. Of course where is the optimal point is arguable.)
Can the compilers be smart enough to figure out the data structure that minimize your algorithm's computation complexity? I don't know. Eventually, maybe, but at that time algorithms will be described in very abstract level, I guess.
Of course you can merge these two characteristics (adding order info to hashtables, which I believe Ruby just did recently). It's a trade off, affecting constant factor.
That's basically my point: there's no reason to clutter the language semantics with the distinction. The reason I'm discussing implementation is to show that it can still be handled efficiently.
