That's exactly how it works (well, "worked"):

(! 736)-> clojure -X:exec :foo 13
a {:foo 13}
b {:foo 13, :a :called}

Tue Jan 11 09:30:46
(sean)-(jobs:0)-(~/clojure/fresh)
(! 737)-> cat src/exec.clj 
(ns exec)

(defn a [m] (println 'a m) (assoc m :a :called))

(defn b [m] (println 'b m) (assoc m :b :called))

Tue Jan 11 09:31:07
(sean)-(jobs:0)-(~/clojure/fresh)
(! 738)-> cat deps.edn 
{:aliases {
:exec {:exec-fn [a b] :ns-default exec}}}

Nice. I think an alternative could also be that it passes the map to the first, and then merges the return back onto the map and passes that to the next. That said, in that case, each exec-fn would need to take a map and return a map. Whereas I think now in theory you could have one return a string for example and the next one take a string as input no?

But in any case, I see why they "don't support" this anymore. I think control on class path is important to have on a per-exec-fn basis. And this functionality everything is ran in the same context. When I think of this feature, I'm automatically thinking build task chaining, which it can't do because of lack of class path control. So it makes sense to push people to build.clj instead and chain things using the shell or babashka, etc.

It's why I generally run my build.clj tasks from a REPL so I can thread several at once.