[euriconicacio]

You mentioned that deterministic test cases for these shapes would be a welcome PR. This is that — test/parse.js only, no behaviour change.

It adds four assertions for parts where ]= appears but no bracket group ever opened. The suite pins what the ]= shortcut exists for — a[>=]=23, a[<=>]==23, a[==]=23 — and pins nothing for what it does when there is no group to serve.

These characterize today's output rather than endorse it, in the same spirit as the issue #558 blocks a few lines below, and they reuse the characterizeParse helper you added with them. That is deliberate: the split moved once already without anyone noticing. role=guest%5D=admin parses one way through 6.12.1 and another from 6.12.2 on, the changelog line for that commit does not mention it, and no test caught it. These make the next such change loud.

The comment above the block names what each case becomes under a bracket-depth scanner, so whoever lands one updates the assertions in the same commit:

'a=b[c]=d'                -> { a: 'b[c]=d' }
'q=%5B1%5D=2'             -> { q: '[1]=2' }
'role=guest%5Bx%5Dy%5D=z' -> { role: 'guest[x]y]=z' }

which is what new URLSearchParams and node:querystring return for all three today.

Verified in both directions, since a passing suite on its own would prove nothing here:

tree	result
main as-is	1113 / 1113 pass
a bracket-depth scanner applied locally	486 / 490 in test/parse.js — the four new assertions fail, and nothing else does

Under that scanner the three ]=-shortcut cases come out byte-identical. That is the control that matters: the new assertions detect a change to where the split lands without being tripped by a fix that leaves the shortcut's actual purpose alone.

Happy to drop any of the four, or to fold them into an existing block instead of a new one, if you would rather.

[ljharb]

Thanks! Made a few changes before landing:

• Moved the new test out of the middle of parses a simple string, so that existing test is untouched, and put it next to the other lenient-parsing characterizations (the issue 6.15.2 parse behavioral change breaks nested bracket query string parsing #558 blocks)
• Renamed it to "currently moves the key/value split to a later ]= when the first = comes before any bracket group", since a group does open in two of the four cases; what they share is that the first = comes first
• Fixed the third label: in role=guest%5Bx%5Dy%5D=z the group opens before the first ]=, but after the first =. The label now also notes that the trailing y is dropped, since that case pins that behavior too
• Dropped the long comment, and moved its history and the expected bracket-depth-scanner outputs into the commit message, adding the fourth case (role=guest%5D=admin -> { role: 'guest]=admin' }) that the list was missing. I also noted there that the literal a=b[c]=d form has parsed this way since 1.0.0; only the encoded spellings changed in 6.12.2

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (37a60ae) to head (3ee412c).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #620   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            9         9           
  Lines         2944      2950    +6     
  Branches       305       305           
=========================================
+ Hits          2944      2950    +6     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.