> Function colours are a useful modelling tool regardless of whether the underlying platform requires it. Without getting into the debate over what valuable in

> Function colours are a useful modelling tool regardless of whether the underlying platform requires it. Without getting into the debate over what valuable information the "async" colour communicates on a platform where, unlike in JS, global state changes could occur at any time due to thread concurrency, any thread can be suspended by either the VM or the OS at any point for any duration, and "async" is no cheaper than "sync", the more practical problem is that Kotlin does not know what colour the platform's operations are. This means that some arbitrary mixing of colours would work on one platform but might not on another. I know some two-colour frameworks use BlockHound, a dynamic "colour detection" tool, but even as a dynamic tool and even today BlockHound sometimes gives wrong results because it doesn't keep up with the frequent changes to the platform. > Not sure how that's any different from a library's perspective than "this API isn't available on older JVMs, so don't use it if you want to target Android". Because it's not about libraries or versions you can upgrade but core language capabilities that differ by platform. It could be acceptable, but it means that there are different Kotlins for different targets. We get a language whose both syntax and/or behaviour differs by platform, and isn't a first-class citizen on any but one of them.