[racket] Where Are List/Container Operations Headed?

Please forgive my ignorance on this matter.

(cons value list)
--- Well, makes intuitive sense to put the container second here.
(map proc list)
--- Reads like English.
(foldl proc init list)
--- Hmm, I guess the association with "map" makes this understandable.
(take list 2)
(drop list 2)
--- OK, what? Why not (take 2 list)?

I am not a programmer by trade, but this kind of plurality of
interface is slightly disturbing. When I am working on programs, I
inevitably look to put containers first. I'm not sure it is always
very pleasing, but it makes *-like procedures a bit friendly. E.g.,
(define (push stack literal)
  (cons literal stack))
(define (push* stack . literals)
  (foldl (lambda (lit st) (push st lit)) stack literals)) ;stupid lambda
Additionally, it can help with syntactic sugar if argument placement
has some consistency to it.

And there is the germ of it. A small issue, really, but composing
container procedures becomes extremely ad hoc because the container
constructors and disassemblers themselves seem a bit ad hoc. The
example itself is a little trivial, I know, but what it means is that
if I later decide to change my stack representation with some other
container---hand-rolled or otherwise---the plumbing is not
particularly extensible unless, from the outset, I roll my own
container procedures and use them instead. (For larger programs, I
have.)

In short, abstracting containers is not friendly, because built-ins
seem to be a mix of ideas.

This is not a complaint, though, just a question. (If I complained
about every oddity I'd never have programmed in any language!) Where
might Racket be going in the future with this? Nowhere? Ideas still
percolating? Has anyone roughly solved the issue? I know clojure
attempted to (perhaps successfully) wrestle with this issue, but I
never looked very far into it. Different containers are often
different for a reason, and maybe this is not a problem that has a
"solution."

Thanks for any insight, everyone,
Deren