The sum of the empty collection should be 0 and not nil.

Urgh...
The description is hard to understand, the interesting clojure solutions time out because they're too slow, and the whole task feels more like fighting the rounding to match the test-case implementation than solving the problem.

@soapie yes, while count itself does not hold on to the head, A will.

So A has potentially rather high memory usage, but is fastest for the most widely used collection (vectors), while B is mind numbingly slow on those but has far better memory performance on the most widely used abstraction (seqs).

The thread is relevant, I think I linked it somewhere as well, but I am not shure.

So pick your poison ;)

Could you rerun the benchmarks with (vec (range 1 1000))?
You'll brobably see that A is O(1) while the others are O(n).

I think it would be far more idiomatic to return a keyword instead of string (:even, :odd),
because as you said "There are two types (even or odd).".

AFAIK not nessecarily.
The way the clojure language bootstraps itself causes some core functions to be written in a weird reduced subset of the langauage.
Also a lot of the core functions are optimized in nonintuitive ways which might not be idiomatic either.

Besides idiomaticity, I don't think that reimplementing core functions is an easy (8 or 7 Kyu) task in clojure. Some of the design choises of clojure are weird to newcommers (see this super long discussion about the time complexity of last https://groups.google.com/forum/#!topic/clojure/apkNXk08Xes), and the devil is often in the detail when it comes to interactions between high level abstractions (seq) and lowlevel constructs (vectors and maps).

Sure :)

Yeah but reimplementing core functionality can't be idiomatic by definiton. Because using the buildin would be the idiomatic way.

Clojure is about simplicity, reinventing the wheel is not simple.

Sure :)

This takes O(N) steps where N = 2 * |lst| - 1, on all collection types.
An ideal solution would take O(1) on most.