I’ve noticed that in Haikuports, when a port is updated to the latest version, the recipe for the previous version is usually removed.
My question is: Is it incorrect according to the guidelines to leave the previous recipe?
How does HaikuPorter handle it if I leave two recipes from two different versions?
Also, how correct or incorrect is it to take versions from the master port, rather than from a specific release? Some people might prefer to have the latest version with the latest commit, while others would prefer to have a stable version from a specific release. What’s the consensus on this?
In most cases on an update the previous one get’s obsoleted, when a new port is build the old vanishes from the depot anyway, eg updating KeePassXC was updated recently, the previous version is replaced with the new one, so there is no need to keep the old recipe around.
Some exeptions exist, eg boost, poppler, openexr, ffmpeg to name a few, to be able to have these around, the recipe names are changed so they can co-exist, for instance, we still have a boost 1.69.0 around, although it’s old (and tried to cleanup on recipes using it), it’s still in use by some ports relying on it, so we keep that one around.
If for some reason a specific port is required (there was some for boost a short while ago), we try to listen to the users need, but without the knowlidge what the user wants it’s hard to keep them. If need be the older recipes are still in the history at the repository and a user could still build from there (you could find python2.7 still in the history, so if you needed it, it’s still possible to build it with haikuporter).
For applications it wouldn’t make sense (mostly) to keep an old version around when it can be updated to newer releases.
EDIT: this is my workflow for haikuports, it’s not a written law. 
I think we trust the developers of libraries and applications to make releases when they feel their code is sufficiently tested and ready for shipping.
Using work-in-progress versions is only asking for trouble usually. There will be more features, maybe, but there will also be more bugs, and making this generally available in a package repository is going to create frustration for everyone: users because the app is broken, developer of the apps because they get users complaining about a version of the software that isn’t yet released, etc.
There are exceptions to this, for example if an application recently upstreamed important fixes for Haiku and didn’t make a new release yet. Or if the app developer themselves wants to provide a work-in-progress version.
Technically, the only limitation is that it isn’t possible to install multiple packages with the same name, even if the version is different. And the haikuporter buildbots will also build only the latest version available. So, either the versions are renamed with a version suffix (for example you will see that we have ffmpeg6 and ffmpeg8 packages), or some other suffix (for example you could call the unreleased version of foo foo_experimental).