I'm sorry I haven't had a chance to read all of the posts on this thread or on the pitch thread, but from what I have seen, there is some systematic confusion about the difference between the proposed comma elision and the semicolon elision that exists in Swift already, and I'd like to draw attention to them. I apologize if someone else has already brought this up.
The proposal, as far as I understand it, does not allow the elimination of all commas everwhere, even when entries are spread across multiple lines. There are well known cases (e.g. an array of enumerators) where you are likely to have commas on every line (because you need them for disambiguation), and there are other cases where you'll end up with commas in some cases - but not others - within the same array or dictionary literal.
If we accept this proposal, the result of this is that Swift code in practice will be a be a mish-mash of different things driven by what happened to be acceptable to the parser, it will not be simple, principled, and predictable. People will literally add commas because the compiler (or source formatting tool) tells them to, which erodes Swift consistency and feel, all for the benefit of removing a few commas.
This situation is strikingly different to the situation with semicolons, where you really only need them to separate statements on the same line. There are cases where you could theoretically have to use them to separate statements, but we've carefully designed the grammar of the langauge so that does not occur in practice on pretty much any real world code.
The proposal does not have this behavior, because side-effect free values (like enum cases) are perfectly reasonable array entries, even though they are not typically useful statements. The proposal does not address this, and (in my outspoken opinion) completely misses the design premise that made semicolon elision work so well in practice.
Others have pointed out very well that common use cases that should work well with a proposal like this (e.g. SwiftPM manifests) actually fail in practice, so this proposal is not even achieving the goal.
The stated claim that EDSLs will be made better by this is not well defended, and there is no robust examination of other ways to improve EDSLs. There are many other things on the list that we should consider ahead of this if that were the actual goal - this is pretty much the last kind of change you want to ever make to the expression grammar of a language, because it has such profound and non-local effects.
I also find it surprising and deeply concerning that we are considering a wide range of syntactic sugar proposals that are trivial syntax micro optimizations (eliding a single return keyword, eliding syntactically light-weight separators) that do not actual affect the clarity of code, or improve higher level expressivity of the language. There is a recent blossoming of syntactic sugar proposals on the list of similar ilk, and there are far bigger fish to fry. This is a really concerning to me direction to see the community take.
-Chris