X> & x>>: auto-transducifying thread macros (now with parallelizing |>> and =>>)

I think at this point, perhaps you are asking in the wrong place, and your sample size will be limited. Core Dev / language design is a useful area to discuss these things. Many decisions w.r.t. language design do boil down to aesthetics, principle of least surprise, and other intangibles. A lot of this used to be discussed on the google group for Clojure; then it migrated to Jira patch notes; I am uncertain where the meatier discussions are today (maybe slack). Alex Miller is at least attentive to ask.clojure, clojureverse, and reddit.

Perhaps the implication of having any value (or simply “more” types of primitive values) be interpreted as an applicable function is that expressions like (1 {1 :hello}(get {1 :hello} 1 work where (1 1)(get 1 1) will just return nil under your implicit interpretation of get (get is somewhat liberal). Should that actually be an error? It’s not novel under existing semantics though (due to get), (:a :a) returns nil too, so there is at least symmetry with existing treatment of keywords and symbols.

Does this convenience create problems for reasoning down the road? It is - by virtue of history now - idiomatic that numbers and strings do not have a function representation. If I see numbers or strings applied in the function position (or say something like clj-kondo does), do we introduce a slew of false positive errors when trying to reason about the code? Maybe this is irrelevant if you are the only one reading the code, or readers will be versed in the expanded idiom.

It would be interesting to see what people who have put much more thought into these questions would have to say.