Turbofan differed from Crankshaft in two key points IMO: 1) the IR changed to SoN instead of CFG (at least for part of the pipeline; the backend remained CFG), and 2) the whole pipeline was redesigned, in particular with high-level node (JS level), mid level nodes ("simplified" nodes) and low-level nodes ("machine nodes") (all of these are SoN), then followed by the CFG nodes which we just call "Instructions" and are closer to actual machine operations. If I'm not mistaken, Crankshaft didn't have this deep(ish) pipeline and different IR levels.
With Turboshaft, we're keeping Turbofan's pipeline (while allowing a bit more flexibility in mixing high and low-level nodes), and "just" using CFG instead. So basically, the current pipeline is something like - in Turbofan (but we're currently moving it to Maglev): graph building, feedback-based optimizations, load elimination, escape analysing, typing, representation selection - in Turboshaft: lots of lowerings, peephole optimizations, store-store elimination, allocation folding, load elimination again, some simple escape analysis, then instruction selection - then we join back the old Turbofan pipeline and do register allocation and code generation on a CFG-based IR (and this was always like this in Turbofan).
The Turboshaft IR is very compact and is based on copying the whole graph entirely during each phase (which can only be efficient if the IR is compact, and only makes sense if enough nodes are updated in the process, which is the case in the backend). In the frontend, we want a bit more flexibility and the ability to update the IR in-place, so we'll use the Maglev IR, which is also CFG, but it's not so compact, and it's easy to mutate the graph in-place over there.
I hope that this is useful information; I can ask some colleagues from the Crankshaft era to chime in otherwise :)
Darius