> and it realizes it wants to test 2 things in isolation, forking is the only way
Why would forking be the only way, when humans don't work like that? You can easily try one thing, undo, try the second thing. Your way is a faster way potentially, but also uses more compute.
This assumes you can retain the same state after an operation.
> "I wonder if this is slow because we have 100k database rows"
> DELETE FROM TABLE;
> "Woah its way faster now"
> But was is the 100k rows or was it a specific row
Thats a great place where drilling bugs and recreating exact issues can be really problem, and testing the issues themselves can be destructive to the environment leading to the need for snapshots and fork.
Again, that is a problem of approach, not of compute. Compute just makes that faster, it doesn't make it possible. It's like you saying the only way to do something is with threads. It's good for some use cases, bad for others, and makes most faster, but it doesn't unlock much
Why would forking be the only way, when humans don't work like that? You can easily try one thing, undo, try the second thing. Your way is a faster way potentially, but also uses more compute.