I also agree: the URL-encoding of parameters in the query string is just a convention
Also a simple table would break with a query string like "?q=1&q=2&r=3" which is also legal:
- If you represent it as a table it cannot be {"q" = "1"; "q" = "2"; "r" = "3"}, which is legal in Lua syntax but as the effect of overriding the key "q" with a second assignment so you just get
{"q"="2";"r"="3"}
- if you use a table of tables, it becomes:
{"q" = {"1", "2"}; "r" = {"3"}} which preserves all values (note that the MIME encoding typically used for POST contents also allow duplicate assignments to the same parameter name, so these names are subindexed by a sequence number and for POST contents, there are several encodings possible: the posted parameters could use many other encodings, including some binary data in many supported formats (as indicated by the MIME type, and with the help of the transport syntax).
But there's still no key for a query string like
"?q&r&s"; you could think you could use anonymous keys, but "?=q&=r&=s" is also legal and distinct, and
"?1=q&3=r&3=s" is also legal and distinct...
Finally using "&" as a separator in query strings is just an optional convention; it is not mandatory for the HTTP(S) protocol for any GET verb or other verb. As well the URL-encoding interpreting the "+" and "%nn" sequences in query strings is also an optional convention; the correct way to represent unambiguously parameters is not inside the query string of the URL , but as an attachment in the content of the query (like for most POST commands).
For the HTTP GET command, the query string is an opaque cachable identifier that just helps identifying a resource or a different version of a resource from an endpoint located at the given path on the specified server. Only the path part has an enforced hierarchival convention (i.e. it is splittable at each "/" and the parts "." and ".." have a special meaning in that context)
It just happens that query strings now are most often used with the convention for URL encoding
