Logan already answered this somewhat but I thought I'd elaborate. During replay we sandbox the entire replaying browser and trap all external IO requests using custom handlers which feed in the original recorded response for that IO request.
Replay does this at the system API level, catching network IO, disk IO, IPC, and any other system interaction done by the recorded browser.
Async dependencies are a tough nut to crack. The main query of importance there seems to be "when was this currently executing code first added to the scheduler". Time travel debugging gives us the infrastructure to answer that question in a single click (and transitively the entire chain back to the initial program execution).
However we haven't implemented specific support for these use cases yet. Our initial public beta feature set is "reversible-execution in debugging", "print statements that work in the past", and "cloud collaboration on debugging through shared discussions on individual replays". I'm oversimplifying but that's the gist.
We'll be prioritizing features to implement and user feedback is of course critical in directing that effort. Features for async debugging, more frameworks support, network monitoring, more runtimes and execution environments, time-travel watchpoints on variables and objects, and different domains such as CI-integration (having replays automatically made for CI test runs) and serverside (easily recording and replaying backend code - starting with nodejs).
The current MVP is pretty breathtaking, and there's a ton that can be done on top of it going forward, and we're excited to deliver more :)