My use case:

I'd like to create a "bosses" category to scale mobs like the Wither or Warden, regardless of where they are spawned, however, I'd like to maintain areas of the overworld where regular mobs are not scaled at all.

Currently this is not possible. The relevant sections of my dimension difficulty scaling look like this:

    {
      "world_matches": {
        "dimension_regex": ".*"
      },
      "zones": [
        {
          "zone_matches": {
            "biome_regex": ".*",
            "biome_tag_regex": ".*"
          },
          "difficulty": {
            "name": "bosses",
            "level": 8
          }
        }
      ]
    },
    {
      "world_matches": {
        "dimension_regex": "minecraft:overworld"
      },
      "zones": [
        {
          "zone_matches": {
            "biome_regex": ".*",
            "biome_tag_regex": ".*"
          },
          "difficulty": {
            "name": "generic",
            "level": 0
          }
        },
        {
          "zone_matches": {
            "biome_regex": ".*",
            "biome_tag_regex": "c:climate_hot"
          },
          "difficulty": {
            "name": "generic",
            "level": 1
          }
        },
        {
          "zone_matches": {
            "biome_regex": ".*",
            "biome_tag_regex": "c:climate_cold"
          },
          "difficulty": {
            "name": "generic",
            "level": 2
          }
        }

However, if the bosses difficulty applies, no other mobs will scale, and vice versa - if the generic difficulty applies (boosting all other mobs), bosses does not work at all in the same areas, and withers will stay at their base HP.

I can make a sort of workaround where the bosses have their own difficulty modifiers inside generic, but that would require setting all zones to at least 1, which I do not want to do. As you can see, the majority of the overworld is left at 0. This would also create a situation where bosses spawned in areas with higher difficulty would be astronomically high.

I am not sure what kind of JSON structure could describe this, while not making the current structure more difficult to understand.
Any suggestions?

Looking back on this suggestion now I don't feel it's important enough to warrant any extra implementation or config complexity - there are multiple workarounds using the existing config structure to implement what I would like.

Thanks for following up regardless.