It is very unfortunate for me that it seems this way to you, but as someone doing precisely this kind of engineering for almost three decades, I can assure you that this is not the case.
"native package managers should install binaries in /usr/[s]bin and libraries under /usr"
Unless one is an operating system vendor (like Joyent, redhat, SuSE, Debian, Canonical, CentOS, ...) third party and unbundled applications must never be installed into /usr: by doing so, one risks destroying or damaging systems in production in the case where the vendor decides to deliver their own version of the same software, and the vendor's upgrade overwrites one's own software and configuration. Long story short: don't deliver your unbundled software into someone else's space. /usr belongs to an OS vendor and to that vendor alone (vendor in this context also includes volunteer operating system projects one is not a part of).
/opt, /etc/opt and /var/opt exist for a reason. Refer to the filesystem(5) manual page on illumos and the LSB FHS specification, sections 3.13., 3.7.4. and 5.12.:
No other package files may exist outside the /opt, /var/opt, and /etc/opt hierarchies except for those package files that must reside in specific locations within the filesystem tree in order to function properly. For example, device lock files must be placed in /var/lock and devices must be located in /dev.
> as someone doing precisely this kind of engineering for almost three decades, I can assure you that this is not the case
Same here.
> Unless one is an operating system vendor (like Joyent, redhat, SuSE, Debian, Canonical, CentOS, ...) third party and unbundled applications must never be installed into /usr
That's what I wrote: "native package managers should install binaries in /usr/[s]bin and libraries under /usr"
"native" as in: provided by the distribution. Not third party.
https://github.com/nim-lang/nimble/issues/80 is about using /opt/nimble and you wrote "If you implement that, you instantaneously take away the ability to deploy applications through OS's automated deployment", hence the confusion.
""native" as in: provided by the distribution. Not third party."
It was a misunderstanding then: I thought native meant the packaging format native to the OS, not packages which come with the OS (bundled software).
Issue 80 from what I understood is about nimble, a packaging format proprietary to one programming language, providing system wide installation capability; this would indeed preclude using native provisioning technologies because those use the OS's native packaging format and hence know nothing of "nimble".
> native operating system package(s), delivering into /opt/nim (and system-wide configuration into /etc/opt/nim) should be provided
No, native package managers should install binaries in /usr/[s]bin and libraries under /usr
> Never bypass OS packaging. Unless you are an OS vendor, never deliver anywhere into /usr, not even /usr/local.
+1