You can find the Filesystem Hierarchy Standard (FHS) version 2.3 at pathname.com/fhs. There is a section about the usr hierarchy. The FHS lists /usr/local as a required directory and writes:
local Local hierarchy (empty after main installation)
Furthermore FHS writes:
The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.
Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.
The different Linux distributions usually don't write software to /usr/local. Instead each file is placed into the filesystem according to the FHS.
If you install software from source (./configure && make && make install) without specific options this software copies itself usually to /usr/local.
The default directory for MacPorts is /opt/local. The MacPorts guide has a description of the internals.
You need to remember that pkg and ports register installed software in the same place (an SQLite database in /var/db/pkg). Neither system records any additional information that a particular piece of software was installed as a pre-compiled package, or as a port. Thus, once a piece of software is installed by either approach, the tools have no way of knowing how it was installed.
When you selected GTK2 support for the editors/vim port, that was registered in the package database. When you later ran pkg upgrade, pkg looked at the package data for vim, and found that GTK2 support had been enabled in the installed version, whereas it is not enabled in the pre-compiled package. pkg upgrade is doing exactly what it should - finding any installed packages that are different from the available pre-compiled packages, and attempting to upgrade them. Those differences can be in version number, dependency graph, compile-time options, etc.
The proper way to prevent pkg from considering a port or package (once installed, there is no difference, as far as the tools are concerned) that you want to protect is to use the pkg lock command.
Alternatively, if you find yourself changing options on a number of ports, you might consider installing poudriere and maintaining your own package repository. It takes a bit of setting up, and works best if your build host has a ZFS storage pool, although it will work if you don't have ZFS; it is a very flexible and convenient way to manage custom software builds.
Best Answer
pkgsrc, the NetBSD package collection, aims, just like the NetBSD project itself, to be portable:
(ref: The pkgsrc documentation).
I other words, pkgsrc provides the possibility to build software for not only NetBSD, but for a range of Unix operating systems. The FreeBSD ports and packages, and the OpenBSD equivalent for that matter, aims at providing third-party software for that particular operating system, only. So the aim is a bit different.
As usual, the FreeBSD project is concerned with supporting as many FreeBSD users as possible (and therefore has the largest 3rd-party software collection), while OpenBSD is driven by developers for developers ("you say you want this, but I don't see a patch from you").
The three BSDs' ports systems have many things in common due to being intimately related, but nowadays, due to diverging development, they are definitely not drop-in replacements of each other. The tools are different, the structure of what constitutes a port/package is different and even some of the terminology is different (a NetBSD "port" is not the same as a FreeBSD "port").
Coming from OpenBSD and therefore familiar with that system's port system (building things in port subdirectories using
makeetc.), I have successfully used pkgsrc on various Linux systems where I haven't had root access, as well as on my personal macOS machine.The strength of pkgsrc is that it offers its users the possibility of having a homogenous working environment across heterogeneous Unix platforms.
However, I see no point in running it on OpenBSD, even though it's definitely possible, as the OpenBSD ports collection has all the software that I need. A FreeBSD user may feel the same about running pkgsrc on FreeBSD.