I’m pretty on board with REUSE! Not just because “code gets moved around and license information might be lost”, but also because e.g. the MIT license is not actually appropriate for non-code, e.g., the .md files or images in the documentation: those should be creative commons licensed (assuming your intent is comparable to MIT on the “code” side)
I also accept that adding REUSE is something that people only do either because they’re license nerds who are procrastinating a bit, or something that’s forced by regulation, i.e. funding / project manager / institutional requirements.
For Julia packages, the current state of things is that the package must have a “main” LICENSE. That license should cover as much as possible, if not all of the source code in the src directory.
Registration requires that this LICENSE is OSI approved.
You can do whatever licensing you want with REUSE on top of that. You should specify in your README how the “main” LICENSE interacts with the finer-grained individual licenses. Obviously, it’s up to you to make sure that your fine-grained licensing gives the registry permission to redistribute your package. Those fine-grained licenses probably should be OSI-certified, but we don’t check that, or anything else related to fine-grained licensing, in any automated way.
There’s a hypothetical world where the registration bot detects REUSE, skips the check for the main LICENSE files and instead checks that all files it wants to redistribute are under a license that permits that. Someone would have to implement and maintain the tooling around that. I’m not sure there’s going to be much appetite for that unless REUSE becomes much more popular / widely required than it is now.
As far as package generators go, I’m not sure how much value there is in duplicating functionality that is probably better covered by REUSE’s own tooling. You can simply run reuse after generating a project to adopt fine-grained licensing, if that’s what you want or need.