I'm specifically suggesting that http/3 could have an implied value for this header if not supplied, so that omitting it was semantically equivalent (and a server could synthesize it).

That's not how HTTP works. HTTP is a transfer protocol, and is not so opinionated on the semantic meaning of the Data it moves. HTTP, HTTP/2, and HTTP/3 were designed to be backwards compatible. It would break that compatibility if there were a semantic change in the absence of the UA string. Specifically, H/3 requests couldn't be downgraded to HTTP/1.1 requests by proxies. There are a lot of proxies.

> It would break that compatibility if there were a semantic change in the absence of the UA string. Specifically, H/3 requests couldn't be downgraded to HTTP/1.1 requests by proxies.

It would not reduce the semantic meaning of HTTP to say "in http/3, the default value of the user-agent header is XYZ (a non-specific modern browser), and if you want an empty header, you must specify the header with an empty value. Proxies and other software translating requests between http/3 and older versions of http should map an omitted header in http/3 to this value, and should map an empty string to a missing header."

It would certainly require change, and it isn't a change likely to happen at this point, but it wouldn't have been impossible, nor would it have reduced the fidelity of http. It simply would have changed the default assumption from "something too ancient to identify itself" to "something modern that doesn't want to identify itself".