Este ensayo técnico distingue entre dos tipos de cambios que puede sufrir una función en una pila de llamadas. Un cambio "normal" —como añadir un parámetro— afecta solo al llamador directo y puede encapsularse mediante programación estructurada; en la práctica, la cadena de propagación suele romperse muy pronto, por ejemplo al pasar un contexto.Background() en Go para adaptar funciones que aún no reciben un context.Context.
Un "color", en cambio, escapa a esa encapsulación: si se modifica una función en la base de la pila, todas las funciones situadas encima deben reaccionar inevitablemente. Es el caso típico de async en JavaScript, donde cualquier función que llame a otra marcada como async debe gestionarla como tal.
El autor propone medir un cambio por la forma del grafo de dependencias que genera: lista enlazada (no es color) frente a estructura ramificada que obliga a propagarse por toda la pila (sí es color). Argumenta que muchos debates confunden ambos conceptos al señalar argumentos como context.Context como colores, cuando en realidad pueden aislarse. También discute la "coloración parcial" que ofrece Haskell y matiza que async no es siempre un color: depende del diseño concreto de cada lenguaje, como ocurre con las nuevas primitivas de E/S de Zig, donde el color reside en el valor de IO y no en la función.