The advantage of using a hyperlink is that consumers do not need an application-specific decoder, they can use their standard reader. And manufacturers can provide additional data (in theory: user manuals, but in practice most likely 404s, tracking and ads).

As I understand it, fields are standardized. I don't think they contain the name of the product (I didn't read the spec), but the other info is there, so no need to hit the servers/db on other servers.

As for the quantity of data, Qr codes have special encoding modes depending on the content. The numeric mode uses 3.3 bits per digit, the alphanumeric 5.5 bits per character (45 characters in the set). Switching modes in the stream is supported, though it adds a few bits of overhead.

Looking at the examples, it looks like the scheme is not as efficient as it could be (pesky slashes, alphanumeric at the end), but that's not too bad either.

There's ways to shrink the bit cost down, for sure. The commas in my example are particularly expensive, for instance, since commas aren't part of QR's alphanumeric set.

It was just a quick expression of an idea, presented in the form of a gripe; it's not a formal specification.

As to consumers, and their hardware: People still get new phones and features can be (and sometimes actually are) added to existing phones. I'm not too worried about it as a constraint; things would catch up soon enough.