Hey 
Ashley and 
DiegoM. I would like to discuss a long-standing issue I've had with Construct, and hope to resolve once and for all. In all my time using Construct engines the only solution I've found to this is meticulous planning, brute force, or utilizing an external level editor, but I think it's worth seeing how it can be addressed internally instead.
Scenario
Say you have a level-based game with a ton of levels. Demonoire is a good example, although a full-scale game will have magnitudes more!
Each level is a layout.
Each layout has a set of essential layers: background, tiles, objects, foreground, etc.
...But now you want to add, delete, move, or rename one or more layers.
Existing Solution
Your only option is to do this, by hand, for each level. Every single of them. Every time you want to refactor your layers in some way. Potentially hundreds or thousands of manual operations.
Close-But-Not Solutions
Global Layers are a way of solving a similar issue, where you want a static set of objects to appear in multiple layouts, like an HUD or Pause Menu. They do not, however, serve as a template to organize, manage, or refactor layers on a grand scale.
Actual Solutions
Recently, the layers bar was updated to display a global layer's sub layers, but they are grayed-out.
Funnily enough, allowing us to place objects in those grayed-out layers, while leaving the master layers empty, would be a legitimate solution here.
With this I'd be able to establish a global "LEVEL" layer, with background/tiles/objects/foreground as sublayers. Simply adding this "LEVEL" layer to each of my layouts gives me my template, and it can be easily refactored by adjusting the master layers.
Of course, I understand that the layers are grayed-out to prevent unexpected behaviors. I only present this as one possible solution that utilizes the existing global layer system.
Soooo maybe we can either...
A) Keep everything as it is but give global sublayers an option to not be grayed-out in other layouts. An "only do this if you know why" kind of thing.
B) Introduce an alternate type of global layer...perhaps a "Template Layer" that functions like a global layer but does NOT inherit the objects from the master layer, and whose sublayers are not grayed-out in other layouts.
Ideally we'd still be able to, in any given layout, add a unique layer into this "template." This way you can have your basic level template but allow special cases where needed.
Final Thoughts
Of course there are maybe other solutions, I'm just trying to think within the box of existing systems. As noted, Global Layers are very close but serve a different purpose. I am not trying to inherit objects here, I just want a sort of Layer Template/Set that I can easily manage and refactor on a grand scale, saving me literal days of arduous work in some cases. Thanks for reading and I look forward to your response!