FYI - This was somewhat of an unfortuate API change.  I'm coming across code that relies on ; also being treated as a separator by parse_qs().  That code is now broken with no easy way around it.

And I'm only seeing things lucky enough to have an explicit test that happens to rely in some way on that behavior.  How much code doesn't?

It's been a mix of some clearly broken code (ex & appearing in the URI being parsed) and code where it is not so immediately obvious if there is a problem or not (up to the code owners to dive in and figure that out...).

The workarounds for people implementing "fixes" to previously working as intended rather than "oops that was a html charref" code are annoying.  Our new separator= parameter does not allow one to achieve the previous behavior if mixing and matching & And ; was intended to be allowed, as it is a single separator rather than a set of separators.

For security fixes, a way for people to explicitly opt-in to now-deemed-undesirable-by-default behavior they got from the API is desirable.  We failed to provide that here.

Just a heads up with no suggested remediation for now.  I'm still unsure how big a problem this will turn out to be or not or if it is identifying actual worthwhile issues in code.  It's certainly a headache for a few.