Create a folder with the following files:
The contents shall be:
In this folder, call java -cp src;cljs.jar clojure.main. In the repl, enter:
If some conditions are met (see  and the explanations below), you'll see the compilation fail with "Can't redefine a constant at <...>".
NOTE: the easiest way to reproduce is to sort the value returned by cljs.closure/add-dependency-sources by a function of our choosing, (comp first rovides) for example. This can ensure that the last element will be a dependency which appears twice (see explanations below). However, in this case we have to use a hand-crafted classpath, which includes our patched clojurescript jar (+ its dependencies, + the src folder).
NOTE: My understanding of the compiler internals (cljs.js-deps and cljs.closure in particular) is very superficial, but those familiar with it can probably follow along.
The journey starts at cljs.closure/add-dependency-sources, invoked in cljs.closure/build. The function takes some dependencies, converts them to a set, and adds some dependencies to it. Things to note here:
the :file entry in each dependency is nil 
the order of (seq (set inputs)) is "random" (or unspecified rather) 
the :source-file entry in each dependency is a java.io.File instance
the :source-file entry in each additional dependency from cljs.closure/find-cljs-dependencies is a java.net.URL instance
there are some dependencies (in the repro case at least) which were in inputs and were added as well with cljs.closure/find-cljs-dependencies (so they appear twice in the list)
The fact that some dependencies are java.io.File, some are java.net.URL instances may be the reason why some items appear multiple times in the set, but I haven't confirmed this.
Next, the computed dependencies are fed into cljs.js-deps/dependency-order, where they are passed to cljs.js-deps/build-index. This function reduces over each dependency (OUTER reduce), and reduces over each provided namespace (rovides entry, INNER reduce).
Here's the crucial part: the INNER reduce associates each namespace in rovides with the dependency, and the OUTER reduce then associates the :file entry with the dependency. But, since the :file entries are nil (see ), the value mapped to nil is overridden with each step in the OUTER reduce. Now, let X be a dependency which appeared twice (or at least twice, does not matter) in inputs. If X happens to be the last element of the dependencies (depends on ), then in the final map (when the OUTER reduce finishes) X will be mapped to nil. Therefore, in the final index, X will be present twice (once mapped to nil, once mapped to the namespace it provides).
Afterwards, these dependencies are compiled, and when the stars align (= sometimes it happens, sometimes it doesn't, both with parallel and non-parallel build) the compilation will fail with "Can't redefine a constant at <...>". This is most likely due to the fact that certain dependency (X), which has a ^:const var, was compiled twice (and some namespaces are compiled twice, this can be observed when :verbose is set to true).
I could reproduce the error on both windows (locally), and on linux (on a travis-ci server).
Please verify that does or does not resolve this problem.
Please reopen if someone can reproduce.