We definitely thought about this, and as you say there could be a collision with apps using a
v= query param. As you also say the main idea is that you can see (well explicitly) the version you are fetching and be sure it is/isn’t the latest version, or a specific version, which would be hidden in the URL if we encoded into it. This is ofc important as we will have safe:// URLs for things like Wallets, SAFE-IDs, or even just a website could be turned into a scam from one version to another and therefore you want to know which version you are using. We even considered using the port part for it, but we again hit the issue of it being assumed to be only 16bits in many implementations/libs even that TCP spec doesn’t set/define a size.
The main aspect I personally consider with this is that the version is as important as the xorname, or type tag, because of the said above about safe:// URLs will be used for many things, so if we have the version encoded in the string we then will need always an app or API to be able to see and/or choose a different version of it.
One thing I also thought was that if we split the version from the URL, not only in the UIs/apps, but in the APIs, then it becomes confusing since we want to use versioned links in the data itself, versioned links should be ofc supported by linked-data, so we definitely want the version to be part of the URL and not just a separate value we can pass to an API or choose from a UI component.
Another aspect, perhaps a minor one but important from UX perspective, it’s about allowing us to have the homogeneous form for NRS URLs, if we encode it in the XOR URL string, the versioned NRS URL will not only have a different form, but also the same issues raised about the query param.
So, I would personally love to have it somewhere else, as explicit as the query param or as the port number part, but I don’t see another clean option based on these considerations.