I've also gotten a related question for squint and cherry if 123N should be parsed as a BigInt

but I said: well, this will likely result into incompatibilities

So we're happy with edn data not being able to be round tripped because of type mismatches?

When I got the question it wasn't about EDN, but about code. You can get backward incompatibilities when people rely on (+ 10 10N) to work in both Clojure and CLJS

when you change 10N to BigInt, (+ 10 10N) no longer will work

Ah, so it's a larger issue with CLJS just not having a proper numeric tower?

I've never relied on this notation myself, so perhaps it's not an issue, but this something that could potentially break people's code as CLJS has converted 10N to a normal number

I'm curious how big that impact would actually be if CLJS' numeric functions were updated to deal with a proper numeric stack that included arbitrary precision integers and decimals.

the numeric "functions" often just translate into raw "+" JavaScript calls

only in cases where + is used as a higher order function, is that avoided

Right, but part of me thinks that's bad default behavior and should only be turned on for specific parts of code that opt into it. But maybe I'm alone there.

it's a huge performance loss if you would go through a function for those cases, but some of that can be avoided using the inference, just like for truthiness (which does go through a function, since that behavior in CLJS differs from JS)