scala-async looks more like core.async's go to me, i.e. it macro-transforms blocks of code that include special constructs into some continuation-passing style. Quasar implements lightweight threads on the JVM (via bytecode instrumentation, which is a language-independent mechanism), and this is a different thing: no special constructs are needed, you just write regular blocking code (only in lightweight threads, that have basically the same interface and usage as regular Java threads) using normal method calls and control flow constructs. Quasar will take care of blocking/resuming/scheduling efficiently.
As for I/O, Quasar integrations allow lots of fibers to make blocking calls _without_ as many OS threads blocking. The underlying implementation mechanism is often to tap into an async API, suspending fibers when an async call is started and installing an handler that will resume them when the async call completes. Quasar includes such an integration with Java NIO for files and sockets and more are available in Comsat (e.g. with servlet async, async HTTP clients etc.).
I agree about typed actors not being too helpful in dynamic, complex and highly concurrent environments, but in some situations (e.g. transient one-receive actors) they can help keeping communication in check more statically. Of course one can just avoid using types if not needed and Quasar behavioural actors are actually untyped.