¿Por qué mi macro de dbt compila a algo completamente distinto de lo que esperaba?

El macro se lee correctamente. El SQL compilado no se parece en nada a lo que dice el macro - y esa brecha casi siempre se reduce a uno de tres comportamientos específicos de Jinja, no a un bug de dbt.

Lea el SQL compilado, no el macro

dbt compile escribe el SQL completamente renderizado de cada modelo en target/compiled/ - ese archivo, no la plantilla Jinja, es la verdadera fuente de verdad de lo que el macro realmente produjo. Mirar el código fuente del macro y razonar sobre lo que debería producir es depurar una capa distinta de la que realmente se ejecuta.

El control de espacios cambia lo que Jinja considera código

{%- ... -%} recorta el espacio en blanco y los saltos de línea justo alrededor de una etiqueta. Omitir esos guiones dentro de un loop o condicional dentro de un macro es la razón más común por la que el SQL compilado sale con líneas en blanco sueltas, o peor, con una coma sobrante dejada por una iteración del loop que no se recortó como parecía que lo haría.

El scope de variables dentro de un macro no es lo que parece

Una variable fijada con {% set x = ... %} dentro de un loop {% for %} no persiste fuera del scope de ese loop como lo haría una variable normal en la mayoría de los lenguajes - este es un comportamiento rutinario de Jinja, no una rareza específica de dbt, y la solución habitual cuando un macro necesita acumular un valor a través de iteraciones del loop es un objeto namespace() en vez de un set simple.