It is still possible to determine what browser caused an exception. The "sec-ch-ua" header is used by Chrome (but only to HTTPS websites) to send the "real" user agent, which for me is "Google Chrome 79" (and I am indeed running Google Chrome 79).

Last time the UA string was useful to me was to show my SO's uncle that iOS Edge is just a "repackaged and watered down version of Safari".

My user agent is "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15". Clearly I'm running a repackaged Firefox browser?

In fairness, real (Trident) Edge fakes the Chrome UA. But yeah all iOS browsers are just WebKit.

IMHO you're right but underestimate the value of what you have mentioned. It is VERY valuable to know which browser caused the exception.

Maybe after people stop using the user agent for stupid reasons it can be made useful again. User agents should be stuff like "Firefox 71.0" or "Chrome 79.0.3945", not "Mozilla but really AppleWebKit disguised as KHTML, but no really I'm Chrome but maybe I'm Safari"

Yes, but unfortunately using the user agent for only non-stupid reasons is a postcondition for the hell freezing over.

Hopefully people will think twice before doing stuff that depend on browser.

Realistically, we will just find another, more complicated and more opaque, and more error-prone, method of fingerprinting the browser version.

There are plenty of legitimate purposes. I use it to disable keepalive for POST requests, redirect to https:// for browsers known to be able to establish a secure connection, whitelist tor browser bundle, detect behavior of Accept: header, which differs even between browser versions, and some other things.