When non-simple-boolean arguments are passed to the and and or macros, the type inferred is simply due to the inferred type of the nested if expansion. Instead we know that we could infer the last type in an and and the first type in an or (while properly handling clj-nil and perhaps also boolean).
Concretely:
can be inferred as type string and likewise
can be inferred as type number.
CLJS-2869-7.patch rebaselines
CLJS-2869-8.patch rebaselines
CLJS-2869-9.patch rebaselines
Note: If is applied then CLJS-2869-9.patch fails unit tests. (My guess is that this ticket's patch makes some assumption that, once is applied, is no longer valid---it is probably handling the clj-nil case explicitly in some way when it no longer needs to do so.)
We don't really need the complexity inherent in this, now that we have truths-induced inference, which covers a highly pragmatic case that this ticket was motivated by.