It amazes me that we're now at the point of standardizing sticking array references inside strings and yet we're still not having a serious discussion about what comes after HTML.
Of course we are. There are numerous new technologies competing to replace the role we have shoe-horned HTML into playing -- look at all the different templating technologies now in development, for example, and things like Web Components. There are also numerous technologies for marking up semantic content and/or styling such data for presentation.
The only thing that isn't changing right now is that we're still stuck with eventually reducing these alternatives to plain HTML for display in browsers, which is about as good an idea as insisting we reduce all styling to CSS and all programming to JavaScript. It's a historical accident, it's resulted in widespread dependence on tools that are nowhere near fit for the purposes they are now asked to serve, but there is so much momentum in the industry that building tools to accommodate the weaknesses as well as possible is the preferred strategy over completely starting over. See also: Almost everything about programming ever.
I've been writing a lot of ClojureScript/React lately and with that I only really touch HTML to include CSS and scripts. It's pretty glorious, highly productive, and makes a very strong case for opening up lower levels to allow new paradigms to evolve - with this set-up, HTML and JS only get in the way.
The browser is now (almost) an OS in a VM and, imho, the sooner we start treating it like that the better.
<input name='kids[1]' value='Thelma'>
<input name='kids[0]' value='Ashley'>That's bad. Really, really bad.
<inputgroup name='kids'>
<input value='Thelma'>
<input value='Ashley'>
</inputgroup>Since these same servers failed to establish a consensus (Django using "a=1&a=2" as array, whilst php uses "a[]=1&a[]=1", for example), someone has to start ...