That’s a terrific feature. But how do you export those changes into other already-existing projects?
How you manage that side of the problem is up to personal preference. For myself I have too many ongoing projects to bother spending my time going around and keeping them all up to date with my current preferences. So my approach is more fix-it-when-you-see-it.
Let’s say I change my mind about how a particular style should look. It made sense to me at some point, but now I find it jarring. So I change how it looks, quickly pop open copy from my main template, import the style settings into it, save as template, and then get back to work in the main project. That’s it for that. The template is my “communicator”, and it’s up to date. That’s all that matters to me in that moment.
Now, you’re asking about how the other direction works. I could go around and update dozens of projects, but I have better things to do. I’ll get around to it eventually, when I’m in that project and I spot the thing I now find jarring. For that I do the opposite of the above: spawn a project copy from the template, import the style (or whatever) from there, and get back to work (no need to save the template since I’m just using it to update my settings in an existing project at that point).
So the template becomes a functional bridge between projects, past, present and future. It’s primary purpose to make new projects, in how the documentation is written, but that purpose makes it really convenient for storing and retrieving common settings, too. I always keep it up to date, and that’s the only one I worry about when changing my mind about something.
All around I think this is the best approach to the problem from the feature set side of things (how we use them is another matter more diverse): provide one with the ability to easily transfer things piecemeal, so that you can choose exactly how much to copy and when.
It seems you’re asking for something that would nuke the entirety of a project’s metadata and replace it with something else. I don’t think there would be a lot of need for something like that. You describe a very specific scenario toward the end—but honestly I’m looking at that and wondering why you have three projects to begin with. That sounds like one project split up into three, to me. Would they not also benefit from a common background and research pool as well, not just metadata? If it’s one story long story, would it not be incredibly helpful to be able to cross-reference different parts of that story right in the same project?
Well—there is no one right answer to that either, obviously. Just know Scrivener has a bunch of feature set for solving that particular problem, of having multi-volume works in one project, whereas it has less of a feature set for synchronising settings between projects in a bulk fashion. That should say something about our inclination at any rate. We think of projects as being containers for works, whatever that entails. Commonly it might be a paper, or even as small as an article, or a book. But it can be a trilogy, or even an entire five season television show, with every episode in one project.