Hi!
The main issue I'm not sure about here is the use of ; as a query string initiator (rather than a query string parameter separator). This use of semicolons is completely non-standard, AFAIK, but it looks like there are some web servers that are actually using it this way. Comments at the pull request itself would be most useful (rather than by email).
Generally, the servers are free to parse the local part of the URL as they like. After all, many servers using REST treat something like /user/2/name as essentially query string, even though / is a path separator. Nothing prevents other servers from adopting the scheme of user;2;name instead or any other way of parsing the local path.
https://tools.ietf.org/html/rfc3986#section-3.4 clearly states that query is delimited by "?". Which means the URLs with ";" are path components, as per RFC:
Aside from dot-segments in hierarchical paths, a path segment is considered opaque by the generic syntax. URI producing applications often use the reserved characters allowed in a segment to delimit scheme-specific or dereference-handler-specific subcomponents. For example, the semicolon (";") and equals ("=") reserved characters are often used to delimit parameters and parameter values applicable to that segment. The comma (",") reserved character is often used for similar purposes. For example, one URI producer might use a segment such as "name;v=1.1" to indicate a reference to version 1.1 of "name", whereas another might use a segment such as "name,1.1" to indicate the same.
So, the specific application can treat path components the same way as query components, but they are still path components. My reading of the RFC also seems to be that ";" is a reserved character, and as such should not be URL-encoded. Indeed, path BNF includes sub-delims without encoding, which includes ";". However, I am not sure I understand other part of the patch where it plays with query string.