API versioning based on URL namespacing is good for allowing compatibility grace period for tools while they catch up with the new version (such as a few years ago when Twitter migrated to API v2, they had the older API available for more than a year to not break millions of applications). URL based API versioning also has some practical limits such as only major versions get their name space, not every single update, which will otherwise cause a disaster for the applications to catch up with. It also assumes that every instance of the service running the same software is bound to follow the same URL based versioning rules (which may be enforced in this case, but the point is still valid on a broader perspective).
The situation with the browser user agent string is very different. It is a legacy of the dark ages of browser war era when Mozilla and IE were the only two players in the market and they were intentionally introducing incompatibilities to gain the monopoly on the browser market. Web application developers started using browser detection based on the UA string to branch the code to execute on respective platforms. Later, when things on the web started to become more standard as the feature set of each browser started to converge, it was in the browsers’ interest to exploit the ways application programmers have coded to make certain features available to users. Let’s take an example here, say Mozilla introduced a unique capability that had no alternative in IE. Application developers added some features in their site with
if UA ~= Mozilla condition to leverage that new capability. Then Microsoft introduced another capability in their browser that was unique to IE in the next release. Some web application programmers leveraged that capability with another conditional. Later when things started to converge on the browser end, and intentional incompatibility war was over, they had no choice but to add every term in the UA that application programmers had used in their past code so that without fixing legacy code, they allow those applications to work in all browsers. Chrome, that entered quite late in the market, had no choice but to carry on with that legacy practice or break the past web.
I would strongly vote against reusing
Server header for this purpose because often web servers such as Apache or Nginx (not the framework) tend to override this header. Even if those severs don’t override it, one would lose the useful information about which server was used to serve the content.