No. Function colors (see criterion 4 in the original article) deal with the idea of "how much of a pain in the ass is it to deal with" which is not really a concept that is a PL theory concept.
The article only lists 3 criteria, not 4, but if you're referring to the final one:
"3. The change may require a change to all functions in the stack."
That's a potential feature of effect systems. An effect generally indicates a restriction of some kind, and depending on your desired semantics it could be totally counterproductive to paper over it with abstraction. And there's a variety of different knobs to twist that aren't necessarily the same semantics that any given implementation of async uses. To use Rust as an example, its `const `effect imposes restrictions down the callstack, and cannot be discharged (const functions can only call other const functions, period), while its `unsafe` effect imposes restrictions up the call stack and can be discharged (by a non-unsafe function that uses an `unsafe` block internally.
The article only lists 3 criteria, not 4, but if you're referring to the final one:
"3. The change may require a change to all functions in the stack."
That's a potential feature of effect systems. An effect generally indicates a restriction of some kind, and depending on your desired semantics it could be totally counterproductive to paper over it with abstraction. And there's a variety of different knobs to twist that aren't necessarily the same semantics that any given implementation of async uses. To use Rust as an example, its `const `effect imposes restrictions down the callstack, and cannot be discharged (const functions can only call other const functions, period), while its `unsafe` effect imposes restrictions up the call stack and can be discharged (by a non-unsafe function that uses an `unsafe` block internally.