I wanted to say, no support in pkg_add for suddenly conflicting packages after an update is by design: there is no way this can't be seen as anything but a regression.
Imagine: you install packages A and B, you go to update them, and suddenly the new versions conflict. The supported cases are classic cases of upstream fiddling with their bits, like for instance the new B is a merge of the old A and B. But anything else will require manual intervention: if the conflict is genuine, the user will have to make a choice. There are several cases where maintainers should be able to do something smart: - the conflict is accidental. Some peripheral files have the same names, which is usually fixed by either renaming/removing the extra files. - the conflicting files are the exact same thing in both packages... which means there is a common small package to build containing the files in question, and making both new packages depending on those common files will be enough. - one of the new packages suddenly provides the services of the other package "on the side", in a slightly different way. That's a perfect scenario for MULTI_PACKAGES obviously. In the case at hand, fvwm2 vs fvwm3, there are genuine use cases for wanting both: fvwm2 and fvwm3 are slightly tricky beasts, and I have BOTH installed on my machines at the same time, because I run into regression once in a blue moon. The main files do not conflict. Versioning the manpages will work. Note that we routinely do much much worse in order to be able to install, say, 10 versions of autoconf at the same time. Tl;dr: there is no tooling solution because it's not a tooling problem. There is some genuine human thought required to give us something that's not a crazy design.
