You can't extend the concept of "coloring" a function to all possible environment and parameters a function needs to execute. That's not because that's a useless concept; I actually find it a very important concept to be thinking about and I often explicitly think in terms of trying to minimize the size of such things in my code. But you can't extend the "coloring" concept that far because you've stretched it all out of shape at that point, into an entirely different concept. All code in all languages everywhere is going to have state that flows through some combination of function parameters through the program and have certain requirements for that state without which the functions (methods/whatever) will not run.

Coloration is a very particular very strong instance of such things that is so strong it causes its own special effects and imposes very special constraints on the code. Generally if you need to call something that wants a context but you don't have one, you just pass in the trivially-obtained "context.Background()" and move on. Nowhere near the level of blockage as a color issue.

"If goroutines are so cheap then why not let the library spawn them."

It's not about cost, it's about software engineering, and it's a particular antipattern you may not know about if you're not in the community. As I said in another post, many libraries "helpfully" spawn goroutines to do a thing and offer a promise-like interface to the results. This is the core antipattern being referred to, which I've seen quite a lot. The resulting API is complexified relative to simply having a function that takes parameters and returns results. If you write such a complex API, an end-user of that API can't uncomplexify it. However, if you write the simple, normal function, an end-user of your API who does want that additional functionality can trivially add it, and moreover, they can add it in whatever other combination of things they may want, e.g., perhaps your library is part of a three-step pipeline you choose to run in its own goroutine, or some other complex threading setup you need. It is better for a library to provide the simple "synchronous" API than to try to guess and possibly even as a result forstall the real setup you need.

It isn't a hard-and-fast rule that libraries must never spawn goroutines, it's a particular set of antipatterns being referred to.