Thanks for this, it helps clarify for sure. That said, I am pretty bullish on moving these kind of librariesinto the platform. It is both one of the stated goals of the Node.js Web Server Frameworks Team and our long term vision for express that more of these common requirements are shared and supported via the runtime not each server framework group.

So while I agree this is a good general technical decision I hesitate to force end users to go through this change if we are just going to ask them to do another breaking change in the future to move to platform supported extended query string parsing.

To me this needs some more discussion so we can have a clear "north star" goal to work toward here. If it happens that this helps get us there, we can totally merge it, but I want to know what that end goal looks like before making decisions here.

If your hope is that node ships a query string parser capable of nesting, it is very unlikely it would have the behaviour qs has (since it's such a mixed bag of behaviours without any standard)

So I think even if you keep this as is, and node ships that one day, you'll be asking users to change the behaviour of their apps.

The only way you would avoid that is by having a qs-like layer around node's parser (if it existed)

If you do that, you're then constrained by a very loosely defined third party API (qs) rather than shaping around what is in the platform

I just ran into a need for this. I'd love to see it move forward. I agree with@43081j that I don't see a path for Node to adopt the logic that lives inqs as that would then diverge from howURLSearchParams works in the browser