You may find some answers there:
In particular give a look at :
/boot/system/bin are for non-gui binaries and scripts, non-system daemon included. The one from packages
/boot/system/apps | demos are for gui applications. You can add yours under a subfolder.
/boot/system/preferences are for gui Haiku’s system-wide preflets.
/boot/system/servers are for Haiku’s daemons.
/boot/system/lib are for shared libs indeed, they better be versionned, but it’s not mandatory and not all are.
/boot/system/develop/lib are where linkers should search libraries to link with at build time. It’s full of symbolic link to actual shared libs under /boot/system/lib, but it also contains some non-shared or only revelant to development process stuff, like static variant of librairies, gcc’s C runtime objects file and also PkgConfig info are located there, under a pkginfo subfolder.
For your own lib(s), you should place it under /boot/system/lib and a symlink to it under /boot/system/develo/lib, for instance, don’t duplicate them.
/boot/system/share is deprecated, it’s now /boot/system/data//… and it’s where your /usr/share//* stuffs should be located now, yes.
/boot/system/develop/headers is where should be put all your devel libs API headers files. Nothing wrong there, our gcc and cmake and so on build systems know where to search headers. Haiku is not an Unix, therefore it has its own directory layout. For portability sakeness, portable software build system should not assume everything is like some Unix or Linux…
/boot/system/settings will host system-wide configuration files indeed. By default packages entries there are readonly IIRC, but you can explicitly allow files to be writable too.
/boot/home/config/settings are for per-user’s config files. Put your under a subfolder named after your package name.
/boot/home/config/cache are for per-user cached data. Again, put yours, if any, under a subfolder named after your package name.
/boot/system/documentation is doc root. For packages’s documentation there is a packages subfolder. Put yours under packages/ sbfolder.
All these are far easier to handle with an HaikuPorts recipe. Which you’ill need to do if you want your package to be automatically rebuild when one of its dependencies is updated, Haiku included.