JSON theme file Style Preset function conflicts with global formatting, exp. behaviour vs. preferred

Hello,

Until recently, the standard behaviour of formatting priority for the various formatting levels/groups within the JSON theme file was straightforward, and presented as below (where the view is top-down in reverse order of priority, so that each step down overrides any settings that came previously where applicable):

With the addition of style presets, it was hoped this same logic would be in place, so that (where applicable) global values could be leveraged in conjunction with style presets, to minimize code and keep the theme file as lean as possible as per best/standard practice. In this way, the same flow (again top-down in reverse order of priority, so that each step down overrides any settings that came previously where applicable) would be in place, only with the added benefit of being able to choose either 'standard formatting' or style preset at the 'per visual/object type' level, as shown:

However, its currently 'expected behaviour' that the Style presets do not work consistently with global values (wildcards), and instead where conflicts exist the option is to either remove the global value in question (& replicate per visual where required instead) if using a style preset that references the same value, or not utilize that particular style preset.

Otherwise, if the conflict is left in place, upon application of the theme the preferred 'default style preset' is not properly inherited when first applying a JSON theme file, leading to various visual errors and glitches (the workaround is to manually select the 'core/native default preset', and then reselect the preferred default). This renders the theme application process counterintuitive and creates too much work for end users at scale (hundreds of reports representing thousands of report pages etc.)

Also, for a complex/detailed JSON theme file, the current 'fix/alignment with expected behavior' means spending a great deal of time undoing the best practice of avoiding code repetition etc., if so much as one visual utilizes a style preset that in turn references a value applied to every other item via global values.

As such, the feature request/idea is that the flow/logic/heirarchy suggested in the second diagram be implemented in the theme file/PBI logic going forward, allowing theme authors to leverage the best of both worlds (global formatting and style presets), rather than being forced to choose.