>> The result from the last call could be cached inside the URI object. It
>> wouldn't be immutable by a strict definition but I thought this wouldn't
>> matter since the public interface is looks like it is.
>
> But then you'd need to compare the string with the one we passed in last
> whenever you want to convert.

Well, you could cache different separators separately, or only cache the
version using the most common separators. But I'm beginning to like the
idea of locking the separators.

> I think locking it in is fine.  Perhaps you could still update the
> separator which would cause the raw query to be re-parsed in the new
> object.

Hmm. I remain a little suspicious of this idea but I don't have strong
opinions. Maybe we should try to write a little web server with a URL
dispatcher (details of server and dispatcher don't matter at this point)
to figure out what would be natural. You mentioned that proxies need
fancier stuff, right? How hard would it be to write or re-purpose an
existing proxy in Scheme? We could clone the existing uri-generic and
uri-common and tweak the interface in different ways to find out what
works naturally.

> It may be confusing, but it's terribly wrong to *not* encode slashes,
> because writing and then re-parsing the URI would change its meaning,
> which could cause all sorts of security issues.

I would have just raised an error unless the caller uses some
specialized procedure (or specialized argument) where slashes and the
like are permitted. If slashes do go into a URL component, I agree they
should be percent-encoded.