There are a variety of scenarios where an end user may want to have multiple versions of a particular snap installed and available at well-defined locations. This is especially common for build-related snaps (toolchains, languages, build tools, etc.), but even for ordinary apps it can be relevant. Talking with @popey offline, it appears that this is not currently possible.
For example, a user may have found a bug or a performance regression and they may want to compare the behaviour of two different releases (a common need for software build-related tools). This may require that they carry out ongoing investigations, so it wouldn’t be practical to keep installing/switching between versions all the time.
Another scenario is where a user is working closely with the app’s developers for a particular upcoming feature. Normally, they want to use the stable release, but they also want to try out a WIP branch or a beta release and report back to the developer whether a particular feature is working. They might be working with the stable release frequently and just poking at the WIP feature branch between tasks, so switching the current snap version isn’t ideal in this scenario (and might be disruptive to what they spend most of their time doing).
For more traditional apps, major releases might use incompatible project files. A user might be working on multiple projects at a time, some of which might use the newer project version and others the older version. If they want both sets of projects open at once, they must have both versions of the snap installed and available simultaneously.
To help with the above scenarios and others like them, it would be great if snapd allowed multiple specific versions to be installed simultaneously. It would be fine if /snap/bin still only contained forwarding scripts for the latest stable release, as long as the user still had the ability to add a well-defined directory to their PATH to pick up a different specific version where they wanted to use that one instead. Alternatively, there might be forwarding scripts in /snap/bin that have version-specific names, but that may be harder to do robustly and safely (you’d have to make assumptions about script names not clashing).
As a more concrete example, if someone wanted to use CMake 3.14.3 but had 3.14.5 already installed, they might just add a path like /snap/cmake/<some_well-defined_version_string>/bin to their PATH to force 3.14.3 to be picked up in preference to those in /snap/bin. We already use an arrangement like this at my current employer for non-snap packages we install in /opt and it works quite nicely. We put a “latest” symlink in /opt/projName/ and each installed release gets its own versioned subdirectory. We simply update “latest” to the most recent (installed) release version. We have the “latest” location on our PATH so we get that by default, but where we need to use a specific version, we just provide the full path to it instead of relying on PATH.