You can make it create a dynamic library (with its own dependencies statically linked). Compare the two products of the SwiftPM package. Such a library would itself be a dynamically linked dependency just like a framework. The difference is that it is a single executable file, not a bundle with resources. Maybe that will suffice for your case, though I have not actually tried to embed one in an application bundle and I do not know what App Store implications there may be.
At the moment, that is the recommended vanilla method. I am not entirely sure what you mean by the words “copy into another project”. The package manager is designed to vend source code, not compiled binaries. Manually dragging products around where they cannot be rebuilt when needed is significantly more fragile than letting the package manager or Xcode manage the dependency tree. Right now Swift does not provide for module stability—it passed evolution review only a few days ago.
I usually get around this in scripts by dynamically querying the package manager for the location with swift build --show-bin-path.
I have long wondered about these myself. Maybe @Aciid knows the reasoning?
In general the inter‐op of the package manager with Xcode does still need work, though it is getting better all the time. In the meantime there are many third‐party tools out there attempting to fill in the gaps until official solutions arrive. @Jeehut has mentioned Accio in a similar thread. Maybe he could tell you if it solves your particular pain points.