I was going to say that this isn't quite right, that you could implement structured concurrency at the language level and have a compiler know how to thread the needle between the different "colors".
But then I realized this is exactly what Go does (with the scheduler intercepting system calls), just minus the structured concurrency point, strengthening your point that these are orthogonal.
Go solves the coloring issue without structured concurrency, that's true. But that statement says nothing about whether structured concurrency can or cannot solve the coloring issue, and if it could, then they're not orthogonal.
I think OP saying that structured concurrency solves the coloring problem is a very similar argument to the authors of Zig saying Zig is colorblind; it might be true for a portion of the userbase, mainly those who are callers, and mostly not for those who are library implementers.
I also think that the structured concurrency feature of "you can expect that the {thread, task, fiber, goroutine} is joned before the function returns" is weaker for the purpose of colorblindness than "you can expect that the {thread, task, fiber, goroutine} is joined before the next instruction is executed" which is what I think you'd need as a single tool for colorblindness
But then I realized this is exactly what Go does (with the scheduler intercepting system calls), just minus the structured concurrency point, strengthening your point that these are orthogonal.