I wrote up a summary of why I think braces as a lexical object! representation won't actually please anyone:
{ Rethinking Braces }... as an array type? - #25 by hostilefork
You get a very minor bit of JSON compatibility, but a mostly useless language feature. The FENCE! proposal is more promising, but has to be considered for what it is...and the consequences it has on strings.
I am a skeptic of accepting something that looks like a SET-TEXT! (set-string!) as a synonym for SET-WORD! for the purposes of this "JSON compatibility".
Reading around suggests the quotes are there because Crockford didn't want to put JS keywords in the JSON spec (like function), and prior to ES5 these could not be used as keys.
JavaScript itself has moved on to where keys that name keywords don't need to be in quotes as of ES5. I imagine it's not unlikely that if JSON was created today it would not have the quotes, and would restrict keys to not having spaces or hyphens...using underscores only for word separators. The fact that spaces and dashes are allowed is more likely a by-product of not wanting to complicate the spec by figuring out how to prevent them.
I think this is where we start to get into the saying no territory I was talking about. As an example, how much trouble does having filenames with spaces in them cause? a lot. Questions arise like: "Do people really need to have spaces in filenames, or was this something that was pursued in spite of how boneheaded an idea it was?"
Embracing bracing for objects is a change that may have value. But I think chasing this JSON compatibility is a move in the wrong direction.