Sorry about the delay on this - I did have it on my list, but as pretty much always happens, so many other things came up I haven't had time to work on it yet. I have thought further about it though and I'm still not convinced the batch update approach is the best one. With some kind of significant new "layer templates" style feature being off the cards for now, I can think of two viable options:
1. Batch editing
This involves basically repeating the core layer editing operations across layouts. To cover all kinds of edits it would probably need to cover the following:
- Batch add layer before/after
- Batch add sub-layer
- Batch rename
- Batch delete
- Batch replicate layer properties
- Batch move layer (before/after another layer, or to/from sub-layer)
- Possibly also batch replicate layer content, although that overlaps with global layers so might not be needed?
Each operation just matches layers across layouts by name. For example if you choose to batch-add layer "foo" after layer "bar", then it would find every layer named "bar" in the project and add a layer named "foo" after it.
Pros: conceptually simple - these are all existing operations in the UI and the idea is just to repeat them across multiple layouts
Cons: there are actually a lot of different operations which makes it more work and potentially a clunky workflow. It is also not obvious how to manage "batch move layer" - typically this is done with drag-and-drop, and it's not clear to me how to design the necessary UI to express the intent "move this layer to there across multiple layouts", especially when taking into account sub-layers. I don't think it's feasible to just skip that option as otherwise you still have the same problem when you want to rearrange layers.
2. Replicate sub-layers
With this approach, you would organize all the layers you want to "template" as sub-layers of a parent layer. Then you could right-click on the parent layer and choose to replicate all its sub-layers across layouts (again matching by name). For example suppose you have layer "parent" with sub-layers "foo" and "bar", and that arrangement is repeated in 100 layouts. Then you could go to any layout, add a new sub-layer "baz" under "parent", and then choose to replicate all the sub-layers of "parent". Then it goes through all 100 layouts, finds the layer named "parent", and makes sure all its sub-layers match - which involves adding the new layer "baz". This would be a single operation that covers adding, removing and moving layers (also going in to further sub-layers), and updating properties.
Pros: simpler user interface and possibly better workflow.
Cons: this involves quite a complicated tree-diffing algorithm to work out everything that's changed and how to update it. In particular handling renaming layers would be difficult with this approach. In the previous example if layer "parent" as sub-layers "foo" and "bar", and you rename "bar" to "baz", there doesn't seem to be any way to tell this apart from deleting "bar" and adding a new layer named "baz". The difference is important if you want to preserve the existing content of the layer, as a rename preserves the content, but a delete-and-add will clear the content. With this approach there doesn't seem to be enough information to know that a layer rename happened so these cases cannot be resolved.
So I think there are probably three ways forward:
Option A: use batch editing, and figure out how to handle moving layers.
Option B: use sub-layer replication, and figure out a way to persistently identify layers to match them up for renames. For example perhaps you could manually enter a layer ID and renames work by looking up layers by ID. (But then what if you want to change a layer ID?)
Option C: a hybrid approach - use sub-layer replication in a way that always assumes a rename was a removal and addition of a layer. Then have a separate "batch rename" option solely to handle the case of renaming a layer using the batch editing approach instead.
I think this is a good case study in how a feature that might seem simple on the surface actually gets quite tricky when you start to dig into the detail of how precisely it works, what the UI looks like, and how to cover all the workflows and edge case that will come up.
I'm leaning towards option C as the sweet spot for a reasonable workflow with a reasonably straightforward implementation. Any thoughts?