The bug

In 1.18/1.19 structure generation was rewritten changing around IDs and more. The explorer_map function in loot tables doesn't seem to be updated with these changes, causing any structure ID input to not function. It instead only takes structure tags, but no # to signal it's a tag. (eg "village" is valid because of "#village".) This is inconsistent with every other place that references tags, as they either use the field key "tag" or precede the value with #.

This loot table should locate a desert village, and put it on a map, but just ends up providing an empty map instead, as there's no structure tag called "minecraft:village_desert".

{
  "pools": [
    {
      "rolls": 1,
      "entries": [
        {
          "type": "minecraft:item",
          "name": "minecraft:map",
          "functions": [
            {
              "function": "minecraft:exploration_map",
              "destination": "minecraft:village_desert",
              "decoration": "mansion",
              "zoom": 1,
              "skip_existing_chunks": false
            }
          ]
        }
      ]
    }
  ]
}

Expected is that either a # is required (like dimension types' infiniburn field), or the "destination" field follows the format used in other placed

 "destination": "structure_id", 
"destination": ["list", "of", "ids"], 
"destination": "#structure_tag"

Original description

Custom structure support, added in 1.18.2, didnt update the function "explorer_map" "destination" field for loot tables. It relies on the old /locate system it seems because like that system it first of all, doesnt need a namespace, and second of all if you for example input "village" it will just select the nearest village, exactly like the old system. "/locate village" is outdated with the /locate command since it has been split up, into one command for each biome specific village.

If you input a structure that wasnt part of the old /locate system, the loot table will just give an unfilled, normal map.