The above attached approach is useful if one doesn't mind shadows being narrowed on mouse over and move, both on the skin being interacted with and all other skins simultaneously, and instead only needing them to appear at rest. Also if the skin dimension transition jerkiness can be mitigated.
While the dual skin approach could be used as-is if one knows the skins will only ever be on the desktop Z position and not overlap other skins or windows.
What would be nice is if Rainmeter had the ability to configure offsets from the edges to define where the snappable area should be (such as the syntax to `DragMargins`), that would work for dynamic width skins. That way one could keep the main skin + shadow in one skin and effectively define a custom bounding box. The downside (if even possible) is if one wanted to dynamically adjust the bounding box/snappable area offset the `[Rainmeter]` section lacks support for `DynamicVariables`, though if it did it'd mean that without any overall skin dimension changes one could change the skin's bounding box on the fly.
Otherwise if the ability to detect z-index were possible in a more fine-grained way such a dual skin approach may similarly become more feasible, for scenarios where overlapping of skins/windows is expected.
If one had shadows wider than the inter-skin margins (such as the illustrations above) and cared about avoiding shadow overlap side-by-side* then the dual skin concept would be the only feasible option (if dynamic z-index were readable), as it would allow for shadows to be placed below both both skins' z-index if they're detected by coordinates to be side-by-side (this was intentionally applied in the static demo further above with the pink 1px borders), while otherwise changing their z-index to follow the main skin if they're not side-by-side as (seen in the GIF demo).
* Existing examples that do this:
- macOS Big Sur's Notification Center widgets. It applies two things: a subtle background 'shadow' that inherits the wallpaper's colors to provide more widget foreground contrast (most obviously if there are regular windows beneath) and additionally applies per-widget regular shadows (which extend ever so slightly into each other's). All of which are behind the actual widget content. Tbf if only replicating the per-widget shadows here, since they don't extend into the content areas, even just having custom bounding box would work while one could add something like MagicMeter for inherited background colors as a separate skin overlay.
- CSS when using the `::before` pseudo element for shadows to effectively place them behind all adjacent content and avoid overlap.
