I was referencing this post and others like it from past summer that say canImport(Darwin) means something different than the longer line it's replacing, though there's obviously overlap.
I did not check all those to see which actually differ: it was simply to show that people are getting fed up and switching to canImport(Darwin) despite it not always applying.
I disagree, that probably refers to something much more fine-grained like #if platform(selector: "kqueue"), so that NIO module would just start working on BSD because it defines its default selector as kqueue. Swift, like most languages before it, has manifestly failed at enabling such capability-oriented versioning, though I would like to still see Swift make an effort to enable it.
What we are discussing here is how to partition capability sets, tied to various technologies like kernels, C libraries, and operating systems. I can't speak to how that would work on Darwin platforms, as I may be the only person in this forum who's never used Swift on any Darwin platform.
I can say how I'd like it to look on linux-based platforms like Android though. Where I would like to see Android end up is to have three conditions for its capability sets: platform(kernel: "linux") for all linux kernel APIs, canImport(Bionic) for Bionic libc APIs, and os(Android) for all other Android-specific behavior. Currently, only the last one exists.
If and when Swift is ever ported to other linux-based OS's like Tizen or Wear OS, all code versioned with platform(kernel: "linux") would just keep working.
If Swift is going to keep growing to new platforms, I agree with @Max_Desiatov that we need to overhaul how we version this code for various capability sets.