Some that come to mind:

On FreeBSD 8 (I think), installing Postfix alongside several other packages that relied on OpenSSL led to Postfix breaking, because the OpenSSL version was updated but Postfix was not. This happened regardless of binary or source install. I don't remember the specifics, honestly, as it's been a while. But, it required manual intervention and patching the port to make it rebuild a functioning Postfix.

On some earlier FreeBSD version, I had a dependency hell situation arise with Apache. Again, some library got moved out from under it, and dependencies weren't sufficiently specific to allow it to be automatically fixed, even with a complete rebuild of all of the packages (which would be a ridiculous requirement that I would still complain about..but even that wouldn't work).

On the same system, saslauthd was utterly broken for months (maybe even years), whether installed from binary or source (there was an issue about it, nothing happened). It required me to manually patch it and update it to make it work.

Also, despite assertions to the contrary, I've found that "mixed" systems of binaries plus ports also often leads to brokenness (the port install will lead to a library being upgraded out from under the binary install software, requiring a port install from source to fix the problem). That should never happen. Random shit should never just stop working because you installed another package, and I've found it to happen at least once or twice on any FreeBSD system I've ever dealt with.

All of this is fuzzy memories. It's been a few years since I earnestly tried to support FreeBSD in our products, because the package management situation was such an ugly mess. Before that some of the kernel limits were problematic (like group membership was limited to 128 or 256 groups, which broke our permissions model for Apache back then, so we had to rebuild the kernel just to make our software functional). There's just been a lot of pain involved in making FreeBSD work for us, and I've spent more fruitless hours trying to make it work than any other system we support (and for a much smaller pool of paying customers...we can count the FreeBSD users on our fingers, vs. a few thousand Linux users). Despite a very low return on investment, I still dig in every few years and waste hours of my time fighting with shitty package management, because I really want to support it.

Anyway, let me be clear about this: If you have to manually patch or edit anything to get a functional installation, your package management tools are broken. In my experience, that's always been required. Admittedly, our stack of dependencies for our software is very large (Apache, MySQL, PostgreSQL, Postfix, Dovecot, Cyrus saslauthd, BIND, procmail, spamassassin, ClamAV, Perl and several modules, bash, awstats, modern Python and Ruby versions, and more that isn't coming to mind right now).

Can I make it work? Yes, I've done it a handful of times in our ten years of making Virtualmin as a commercial product. I honestly want to support FreeBSD, and always have wanted to support FreeBSD. xBSD users are almost universally extremely competent; they file useful bug reports, they're helpful when I have problems based on the limits of my knowledge of FreeBSD. But, it's always a massive pain in the ass, and when a new version rolls out, I find I have another stack of problems to work out manually. Most of those problems are related to package management failures.

Also, while xBSD users are often awesomely bright folks, they're also extremely defensive, to the point of it being difficult to address problems (like this one). We're talking about a post in the DragonflyBSD list that discusses this very problem, the exact thing I'm belly aching about, is a thing that is acknowledged as a longstanding issue in ports by the developers who have made some changes to try to address the problem. Why are we arguing about whether it happens? (I understand DragonflyBSD and FreeBSD have diverged many years ago, and there are significant differences, including in package management, but this seems to be a problem of ports in general, in my experience.)