I too have chafed at the restriction against executing a package from another project; like everyone, I have a small number of tasks and packages that perform those tasks that are truly universal in my framework; logging, compression and encryption, etc.
My solution is a little different from yours : These pkgs don’t exist in a project or the catalog at all. Instead, they are in the file system in a child folder of the Resources location that holds other supporting files such as binaries.
Sure the package execution task requires a little more config, and the external packages themselves require a little extra work, primarily to get at passed parameters properly, but this approach has worked extremely well for me.
It doesn’t add anything to the complexity of scripted deployment since, again, there are always other external dependencies that are deployed to the file system.
My framework projects have a configurable value to point them to the overall Resource location, but each external resource package is allowed its own override, whether folder or down to the package name. This is nice because, although the external tasks change very rarely, each can be versioned on its own and, if necessary, the projects can upgrade to new resources gradually. (I have actually never needed to do that much granular upgrading, but always thought I might, so built it in.)
What do you think?