JSON is a lowest common denominator. The features that you just specified are not directly available in JavaScript. Therefore data represented in this new format will be very, very clunky to access from JavaScript.
You say "lowest common denominator," I say "subset of JavaScript." In fact, JSON objects are clunky to access in some languages, like C. JavaScript's lack of proper sets and maps is a weakness of the language's standard libraries and is in fact being corrected. It seems quite unreasonable to me to use JavaScript as some sort of Platonic ideal of a programming language, where anything that has a different feature set is automatically bad.
It's kind of a big leap to go from "This is not a strict subset of JavaScript" to "You're ignoring the web." If you really want to deal only with JavaScript-native data structures, I can't see any reason why you couldn't deserialize EDN into those. If you really like the added data structures in EDN and don't want to lose those in your JavaScript program, you could just use Mori or something similar.
If improvement in JavaScript, which sits in browsers that developers have no control over, is a prerequisite for the success of a protocol, that protocol will be irrelevant in the web world.
In general when you're trying to achieve interoperability, any features and distinctions supported in your data format that are available in one language and not in another will be causes of interoperability problems.
For instance with JSON, the format allows you to differentiate between values that are numbers and values that are strings. Languages like PHP, Perl and JavaScript do not particularly care about that distinction, and therefore coding values consistently is hard in those languages. (You can guess, but sometimes guess wrong - your zip codes are usually represented as numbers and sometimes strings.) Languages like Ruby and Python do care about the distinction, and so applications can have difficulty accepting JSON from the previous languages.
This new format allows more places for this kind of issue to exist. We have distinction between different types of integers. We have symbols (2 kinds if you have them). We have sets. We have 2 different kinds of lists. And we have a plethora of possible extensions, every one of which can behave differently in different implementations.
When both sides speak Clojure, this is going to be a very convenient choice. When they don't, every one of these obvious features is going to be a source of headaches down the road.
That is why data exchange formats should be in a least common denominator between the languages in question.
If I were to agree with some of your points, it would have to be the distinction between a list and a vector seems rather silly.
Having those as distinct different types in a data exchange-format seems awfully (lisp/functional-language) implementation specific. IMO conversion from "generic list" to "whatever type of list makes sense in your domain" should really be done outside of an data-interchange format. A data-exchange format should not need to meddle with any list besides "generic list".
I do think sets (as opposed to lists) brings valuable semantics, though I can see how that is up for debate.
Otherwise, you bring up fair points, but I don't mind a format with ambition. Merely presenting a new JSON would not be very exciting.
There is some redundancy between vectors and lists, admittedly.
However, edn is not without legacy. Part of that legacy is Lisp and s-expressions, and deserves some respect and accommodation. If that means readers map the [] and () to the same code path, well, that's not much work. Writers can always write only [] if they prefer.
Having the distinction has proven tremendously useful to Clojure, and might to other applications as well. In particular, consider DSLs written in edn, which, like Clojure, might need to distinguish calls or grouping from list/vector data. For all the bitching that goes on about parens, few people would want to work in a language without them :)
Maps with non string keys are handled differently even in languages that do support them. Are two instances of an object used as a key the same for example. This may vary depending on the type of the object.
> The features that you just specified are not directly available in JavaScript.
JavaScript has hashmaps with non-string keys, they're just not exposed by JSON. Also a set can be treated as an array in a non-clunky manner. Likewise for treating an integer as a Number.
I'm not sure the design goal of edn is to actually be consumed from JavaScript though?
JSON is a lowest common denominator. The features that you just specified are not directly available in JavaScript. Therefore data represented in this new format will be very, very clunky to access from JavaScript.