I think that folding everything into a single layers stack has the peril of making the reuse of shared elements and its relationships too abstract and difficult to follow, specially if you open an icon from its HVIF version, where all the names are stripped.
The way the UI is distributed now has the virtue of showing to a good degree the internal logic of the format, where things that exist once (but can be reused many times) are showed only once in a specific list.
The only one that I will get rid of and integrate into the shapes list is the Transformer list, because they are always specific to each shape, thereās just two of them and it takes up a fixed, mostly empty space that could be used to have more room for the other lists.
The other lists contain shareable elements so I think they must be kept.
That said, having the shapes list shown in this way, with all the linked paths, styles and transforms next to each shape or layer could be a good complement to better grasp the structure of an icon at a glance, even if a bit redundant.
I always thought that the āThings should be done as simple as possibleā principle has an implied continuation that has to be taken very seriously, that is: āā¦but never more simple than possibleā.
Iām sure everyone has some example in mind about something that was simple enough, but was made more complicated in an attempt to simplify it too much, at times for cost reducing reasons in physical products , other times taking to the extreme some UI trends (gestures for absolutely everything, hiding scrollbars, flat UIs), but I digress.
I try my best to only suggest things that make sense directly inside Icon-O-Matic in the context of creating efficient icons 
I did already go a couple of times through the route of prototyping something in WonderBrush and exporting it in SVG to load it in Icon-O-Matic, but it ended up being more cumbersome.
Either the icon ended up more bloated as every element became a different path because WonderBrush doesnāt do path reuse, or I had to redo practically everything again and it made more sense to do it directly in Icon-O-Matic from the start.
The only things that were still useful were to do some perspective transformation, which is about to get solved, and to trace something from a bitmap image, mostly solved with the recently implemented reference layers.
True however, a new way to use WonderBrush has opened up now with reference layers, that is prototyping in a more relaxed way, exporting as a bitmap, and tracing directly in Icon-O-Matic with all its native advantages.
Regarding layers, they are just a way of organizing things, a mere UI convenience to select at once a group of shapes, they could be called ālayerā, āgroupā or something else.
It even crossed my mind to suggest that layers could be discarded once the icon is exported to HVIF, as it happens with names. But given that the data about which shapes have been moved or transformed together will have to be preserved in some way, it didnāt made much sense, because they will be just a way of exposing something that is already happening internally, no?
At least that is the concept of layers I had in mind, something simple integrated directly in the shapes hierarchy, no layer masks, no blending modesā¦
No problem. As long as a bunch of shapes can be transformed at once in an filesize efficient way, I donāt mind having to select them manually, Iām a happy mouse 
Ok, thatās right, step by step.
Cāmon, lets advance 
. Currently, they canāt be applied to multiple shapes at a time. It would be really space-inefficient to apply the same perspective transformation to each shape individually one at a time. The only use I can think of is applying perspective transformations to reference images, though I canāt imagine that coming up all that often.
) doing a perspective transformation directly to the paths inside Icon-O-Matic.
