I agree that key-value sets (hashmaps, associative arrays, whatever one calls them) are even more convenient for programming than lists are. A pet idea is to create a Lisp that takes the hashmap as its native representation. (My cofounder is working on it!) However, it would be beyond tedious to have to assign every code element an explicit key, so in practice one wants to generalize s-exprs into what one might call t-exprs ("table expressions") in a way analogous to how Lua lets tables have a special integer-indexed array portion. Semantically, everything is a table (hashmap); notationally, most forms look just like s-exprs. But now they can be augmented with arbitrary key-value pairs.

I don't feel future-proofing is as big a deal as you do, but I do think that certain programs and (especially) tools would be easier to write in a hashmap-based Lisp, where the programmer and/or tool could attach whatever metadata they wanted to any section of code. There are potentially some order-of-magnitude wins there, I think. Production Lisps usually tack on various kinds of magic metadata anyway (e.g. symbol-plists, docstrings, Common Lisp's declare, Clojure's metadata). The above idea would unify all of those by promoting the underlying generic construct to first-class status.