Hey there,
realistically all this will take quite some time to pan out and fully understand all the implications on APIs.
However a few "simple" things that can be done early are:
The concurrency design offers Task.Handle APIs which effectively are "futures" but married together with the async world. When you look at it you realize it's not very special and simply has a func get() async throws -> T that can be awaited on. NIO could adopt this pattern and offer an awaitable function on EventLoopFuture #if swift(>=6), this function has to be invoked from an async context through... so that's a bit more tricky so all NIO functions would need to be async as well -- that is harder to adopt without breaking compat.
It is not entirely clear how NIO would be expressed as actors, I think we'll need to learn and experiment much more to see if, when or how it is viable to do so. Handlers are pretty similar to actors in that they isolate state and run not concurrently -- the language design offers ways to optimize away not necessary "hops" between actors -- however it does so by actor identity -- NIO needs more than that, it needs to do so based on executor identity. NIO will want to "don't hop to other executor because that executor is the same event loop as my event loop" -- today's concurrency design does this check only about actors ("that actor is not me, so perform a hop"), we would need to extend this to check executor equality.
In addition to that we will have to ensure in the concurrency design though that an actor can be put on a NIO EventLoop (i.e. an EventLoop be an Executor) which has specific execution semantics after all -- I can say that I'm definitely looking at this topic and trying to ensure that the actors are flexible enough to express other executors rather than "just" some dispatch based one. If we had this, actors "on" EventLoops could become viable... Caveat that this is just rough ideas and not something we've planned out at all so far.
Long story short: Adoption in NIO likely will require a major version bump. Other than adopting awaitability on futures it is not clear, yet, how language concurrency will be adopted in NIO.
Cory and the NIO team will likely chime in with their thoughts shortly though 