Yes. The way I envisage this working is similar to how tools like Cargo and the RLS work today - we run a subset of appropriate tests when a PR is merged to the std repo (for example), and then the full set of tests when we update the sub-module/crate dep in the main repo (which would take as long as today, but would happen much less frequently).
Of course merging updated std into the main repo might not work and someone would have to then fix up the std repo. So we'd be trading that bit of manual work for the improved turnover (and other benefits). I don't think we sacrifice correctness. Of course the 'fixup' work is happening today, but it is happening in individual PRs, in the 2-stage model, it would happen in bigger batches and would require some dedicated attention from somebody.
Yeah, this gets close to the "Lieutenant" model, and it's their job to deal with integration stuff. This is what happens already with me and the books.
Ah I see. This indeed doesn't sacrifice correctness, but also doesn't try to tackle the build time timeouts problem (which is fair). I suppose this would potentially be used in combination with moving to a CI provider with longer timeouts - because there are less individual merges to master, longer builds aren't a problem.