This is a big change (in terms of impact, not lines), and I'm not entirely sure its the correct change, but something needs to be done in this area.

Problem

The PURL spec describes qualifiers as being an & delimited sequenced of = delimited key value pairs where the value is percent encoded, and the section on encoding describes a minimal set of characters that are supposed to be percent encoded in different contexts. This looks a lot like x-www-formurlencoded, but x-www-formurlencoded encodes almost all characters besides the ascii alphanumeric set, and has a special behavior where ' ' is encoded as '+'.

I am aware of thirteen PURL implementations:

That means if you're working with qualifiers that have spaces or plus signs in their values, it's fairly likely that software using a different implementation of PURL will interpret the PURLs differently. This may also happen if your PURLs have plus signs in their versions (deb) or spaces in their names (swid) and the implementation incorrectly decodes the name and version as if they were qualifier values (see below).

6/14 of the implementations are decoding '+' as ' ', so here's why I think it's better for the spec to specify '+' is '+':

1. The spec doesn't say it should be x-www-formurlencoded, although it could be argued that it is implied. Using x-www-formurlencoded would make PURLs more compatible with regular URL parsers and utilities (but still not 100% compatible IIRC), at the expensive of making the specification more complicated.
2. Three of those six implementations that encode and decode qualifier values as if they were x-www-formurlencoded also encode and decode other parts of the PURL, such as the version, as if it were an x-www-formurlencoded value. This is not standard URL behavior and it is not part of the PURL spec. This seems like an implementation mistake, incorrect regardless of how the qualifier values are encoded. (package-url/packageurl-dotnet, package-url/packageurl-ruby, sonatype/package-url-java)
3. Having a different encoding scheme for the qualifiers vs the rest of the PURL, while common for regular URLs, can lead to confusion, both for implementors (see above) and for users when dealing with PURLs that contain plus signs in and out of qualifiers.

Proposal

1. ' ' decodes as ' ' and '+' decodes as '+' (as in 8/14 implementations)
2. In qualifiers, ' ' encodes as %20 and '+' encodes as %2B (as in 8/14 implementations) to avoid ambiguity when PURLs are parsed by implementations pre this change (unfortunately, there's nothing we can do about parsing PURLs created by implementations pre this change)
3. In the rest of the PURL, ' ' encodes as %20 and '+' encodes as '+' because that's how the spec was written, it's not ambiguous that the rest of the PURL might be x-www-formurlencoded, and plus signs seem like they're common enough with some package types that there's benefit in keeping them unencoded.

The spec is updated to be specific, new tests are added to the test suite, and incorrectly escaped examples in the package types spec are updated to be consistent.

Unfortunately, this requires changes to at least 7/14 implementations to get everything aligned, but they should be minor changes.