That's what bothers me most about FreeBSD. I also think that you should always keep the last working version before building a new one.
That only works for something that is standalone, does not depend on anything else nor does anything else depend on what it provides.
Especially if one is following "latest".
Package A depends on QT version X.Y
QT maintainer updates to version X.Z to pick up security updates and maybe has some API changes because of deprecated features. QT version X.Z builds successfully.
Package A needs to change dependency to QT version X.Z and rebuild. Package A does not have the same maintainer as QT, so all the QT person can do is email "QT has been updated to X.Z. Please adjust your packages as needed".
Package A is updated and fails to rebuild because of an API change between QT X.Y and X.Z.
Leaving older version of Package A that needs QT X.Y gives a user a broken Package A on their system. pkg upgrade picks up QT X.Z which removes QT X.Y from their system, leaving an older Package A locally that will not run because of ld errors finding shared libraries.
Waiting for EVERYTHING to build 100% before pushing to external repos means everyone is waiting longer on things they may not care about. That is not a desirable thing.
pkg upgrade -n tells you explicitly what will be installed, reinstalled, removed. Like a horse and water, the command output can tell a user what it will do but can't make the user RTFM.
Quarterly has less churn than latest, but may lag versions/security updates. But sometimes things still break or fail to build and take "forever" to resolve from a user POV. In between Quarters, there is very little churn (things like browsers seem to be the biggest), but understand that "next quarterly is a tag off of latest at some point in time" so it may take time to ensure all the packages you need build.
Building everything for all supported versions (versions and architectures) is non trivial in terms of resources: storage, CPU, network.
The only way for a user to truly control things is set up your own port building server, track what you want, update what you want, rebuild when you want.
Following the different ports mailing lists (bugs, announce, ports) can help limit your pain at any given point in time.
Above is just my opinion, based on the way I do things, based on my tolerance of waiting for something that someone else is doing at no cost to me, so take it for what it cost you (maybe a headache from reading too many words)
