"It's also separate from changing how URL's are defined."

URLs, as defined on the web using http and https, specify the use of DNS, which itself brings in a lot of semantics that are not optional. If you fundamentally change how domains are identified on the web, you're going to fundamentally change how HTTP & HTTPS urls are defined, either by rewriting the current definition or putting a new one on the side.

Since we're probably playing telephone here, at least two steps removed from the source, it's difficult to tell if they actually want to rewrite what "https://" means, or if perhaps they would create a new protocol ("ghttp://") which would define domains differently.

Here's a hyper-quick stab at an example of what that could mean. Imagine a world in which

    ghttp:Bank of America: {
        "server_namespace":"accounts",
        "title":"Account Management",
        "subhead":"Account Details"
    }

is a legitimate "url" that you could use to link to things. The key here is not in the mere embedding of information, since of course you could translate the literal information contents into a URL no sweat, but that the semantics of ghttp would be redefined to A: change the lookup of "Bank of America" to use Google's home-grown domain-like validation system that is run like the highest-end TLS certificates B: contains a specification of how to render such URLs out in the user agent and C: probably contains all sorts of other exciting things that can go in that JSON blob because why not. Certainly the standard will not be a one-paragraph sketch on HN but run into the hundreds of pages, because that's how these things go.

One of the benefits, for instance, might be sold as making it easier to parse the URL with a JSON library than bashing regexes together as we do now, which is incredibly error-prone, speaking as one who has made many errors myself.

Technically, that's still a URL, if you ignore the newlines I added for clarity. It turns out that if you read the standard, there's nothing about URLs containing DNS-based domain names; that's a specific detail of HTTP, HTTPS, FTP, and several other schemes, but not technically a characteristic of a URL in general.

So I would consider it a valid interpretation of the article (which, as I said, is rather vague) to say that what is meant by "redefine URL" is "redefine the set of URLs that user agents are used to using" and that Google may want to create a new protocol scheme.

It's also faintly possible they want to actually redefine "https://" itself, but, while there's technically room to do that in some sense, I don't think it will succeed.