I appreciate that it's a bit frustrating to have someone vaguely identify an area of concern and clarification and actionable suggestions are much more valuable.

There's two things. One is that the data structure ontology[1] is difficult to internalize because of its complexity. When I write Clojure code, I consider the capabilities of the data structures being passed to the function. I think we have some implicit understanding of this early on. You expect the type of such and such to support seq-ing or deref-ing or something else. You're thinking in terms of capabilities and that's good. But if you want to be exacting, at some point you'll have to be able to point to an interface or several in the diagram and say, "yes, I really do expect something that conforms to IPersistentVector or IMeta or something else. In order to preserve backwards compatibility, this is more confusing than it needs to be. Moreover, at that point, you're not in Clojure-land anymore.

My second point is that at this step in the narrative, you're reading Java code and the illusion of 100 functions is broken. I ask myself, "Why, aren't Clojure data structures implemented in terms of protocols?" There's a perfectly good way of abstracting functionality that seems good enough for users, but not good enough for standard library implementers? It feels like the answer is, "We don't want to break Clojure1.x and we don't want to deal with the Python3 problem." Which is fair, admirable even, but it still leaves me left wanting. I think there's a simpler, more consistent Clojure hiding in there, waiting to be let out.

Apologies for the awkward way this reads; I simply wanted to get it out before lunch time.

1. https://raw.githubusercontent.com/jafingerhut/clojure-classe...