Just curious why you think it should be displayed that way?
The docs for URL are pretty clear that opaque do not start with / and comes right after the scheme.
What you are expecting is the general form + path.

You are correct that the documentation clearly states that the host is not part of the opaque. I should have given some more background information when creating this issue.

I thought the behavior was incorrect because when you include the host part in the Opaque your HTTP request would result in a different request (not necessarily invalid) than when the Opaque would not be set.

Using the http.Request.URL value returns unexpected results.

Example:
https://play.golang.org/p/CMUTLohe-V

No Opaque:

GET /opaque-set-in-url HTTP/0.0
Host: example.com

With host duplicated in Opaque:

GET http://example.com/opaque-set-in-url HTTP/0.0
Host: example.com

But according to rfc3986:

everything after the scheme component delimiter (":") is considered opaque to URI processing

So according to the name 'opaque' it's not invalid but it leads to unexpected results for regular use cases.

Unfortunately, it was required to use url.URL with Opaque when the URL contains any special encoding, especially base64 which could include an encoded / (%2F) where the encoding will be removed and threaded as a directory.

But when I just tested this it doesn't look to be a problem anymore, so or I got confused about what character caused the problem or it was resolved in a go release since I wrote this code a couple of years back...

I will try to dive into my archives and try to replicate the original issue that forced us to use Opaque.

The fix using Opaque was implemented about two years ago. Just verified with tcpdump and the original problem looks to be resolved in the current go version.