The browser string helps to identify if the browser can perform certain functions. So send a string that specifies "server-visible capabilities" (ie: what the user wants the server to know about the capabilities of the browser) instead. Then no browser, OS or other potential privacy loopholes exist.
But what if you don't want the server to know anything? That's the point about sending a capabilities string. If you don't want to specify, there's no need to. Having said that, setting a bit that indicates "HTML 4.01-compliant" is not revealing anything terribly informative to anyone, since that's going to be true of 99% of user agents at this point. Which means you're not part of the 1%, but that's about it.
HTML 5 is the only awkweird one, as you'd have to have a bit for some generally-agreed group of functions, since there's no fixed standard. (IIRC, that's going to switch to having a "rolling development branch" and fixed "stable snapshots", but for now there's no stable spec you can identify with a simple flag.)
True, some browsers implement subsets (and/or extensions to) approved standards, but frankly the headache for developers is to support those kinds of freaks. A fixed list of supported standards you can switch between is really what you want. Special cases for every browser make for something that is unmaintainable, as anyone who has developed a web app can tell you. Freak cases really should be reduced to "nearest available standard" where at all possible.
This satisfies all the requirements of the server, for behaving correctly on multiple browsers, without giving anything away that could be misused.
Furthermore, since I'm saying the capabilities string is a bunch of flags, you can specify masks per site or site grouping if you want to conceal some information from some servers. (This makes user tracking via the agent impossible, since the agent can now vary and there's fine-grained control over how it varies.) Not a million miles from how security is handled in every other case.