Yes I was just talking in a general sense that JSON should not go all XML and mutate. In some cases I have added layers like this for instance in a C++ parser for game engines it allowed comments in the json but were stripped out at runtime on load and on send/receive from the services. But conforming to JSON that current browsers, libraries etc can use.
I see where you were going with it, ES5 support as a baseline is nice, also comments are nice but also bulky to a streamlined messaging format in most cases (config is usually yaml or some other format for this reason maybe).
I guess the naming is what maybe might cause some confusion and a good engineer makes things more simple not more complex, the simplicity of JSON is hard to achieve with such success but it is also its killer feature so that should be recognized. As long as we don't have to support 50 different 'modern JSON' formats then we are good. There are some good ones like BSON for binary JSON. I guess JSON5 works for your ES5 support.
I think here you have good reasons for your work but it goes back to the age old be 'conservative in what you send, liberal in what you accept'. That standards agreement makes everything work and to me being an engineer is taking complexity and simplifying always, bloat is bad. Here it isn't that but XML started out simple as well and became a verbose, bloated hell so people get touchy with JSON hehe.