Really depends on where you're from.

OP already mentioned in his area it's phonetically mostly "ew".

I'd say a lot of germanic areas also do something I'd describe as "oi". That'd also make one inclined to use an "an" when speaking.

Ah, yes, the KDE people are definitely the people I trust most to deliver a reliable system and not go crazy chasing incongruent rewrites of things while abandoning what works...

/s

My 2c (opinions may vary, etc, etc): I think that doing percent-encoding shenanigans is going to be widely perceived as "ugly" and will severely hamper adoption. I'd reconsider.

I think it's quite likely that people are going to care a lot (lot) less about the semantic distinction between <namespace> and <name> (which is a semantic, handwavey, somewhat indistinct subject to begin with) than they are going to be turned off by percent encoding.

There's two broad categories of possible outcome for that kind of friction:

- Either people-in-the-wild do implement and obey the percent encoding rule, despite the friction (and adoption gets a debuff);

- Or, people-in-the-wild will just quietly ignore the percent encoding rule. And I think this is significantly likely, considering that (iiuc) the only consequence is that the parts with slashes end up considered <name> and never <namespace>.

Neither of those outcomes is totally bad, but they're both unfortunate. For the first one, an adoption debuff is never great. For the the second one (e.g. rule mostly ignored), there's other potential negative outcomes: the community might be fractured; and also, that figuring out what to do when writing a good renderer and some people followed the percent-encoding rule and some didn't... is going to be very, very ugly.

On the other hand, if the spec doesn't recommend (or support) percent encoding at all... yes, it loses the ability to express some <namespace> values. But is that actually something that's truly load-bearing? Maybe dropping that expressability is actually a viable trade.

soo..... what's the guidance for when package names include a slash?

such as approximately everything in golang, which very often matches e.g. "github.com/*" as a package name?

Do would PURL suggest that "github.com/foobar/go-whatnot" should be parsed as namespace="github.com" (odd) and package name "foobar/go-whatnot" (since there aren't any more slashes in the blessed separators)?

Warpforge -- project website: http://warpforge.io / https://github.com/warptools/warpforge -- is a project I work on that's heading a bit in this direction. Hashes in + build instruction = hashes out. It's really a powerful primitive indeed.

Building big sharable package systems is indeed a second half of the problem. Figuring out how to make the system have the hashy goodness AND be usefully collaborative with async swarms of people working independently and yet sharing work: tricky. We're trying to do it, though!

We have our first few packages now published, here: https://catalog.warpsys.org/

You can also see _how_ we build things, because we publish the full rebuild instructions with each release: for example, here's how we packaged our bash: https://catalog.warpsys.org/warpsys.org/bash/_replays/zM5K3V...

I'm in #warpforge on matrix with some collaborators if anyone's interested in joining us for a chat and some hacking :)