I don't really see the point of disabling the borrow checker anyway. I assume the intent is that it would make incremental development easier, but as someone who has written probably 100kLOC of Rust I feel like it would take a ton of work to implement (ie: making `miri` radically more powerful and generalizing it) and solve... no real problems for me. I get that a beginner is going to see bigger wins there since they will hit borrow checker errors earlier, but even then, I learned rust in 2015 when the borrow checker was way stricter, and I don't think I fought very much with it - I learned immediately that I could clone my way out of almost any issue.
IMO a far better investment would be into compiler errors giving better hints, or IDE improvements to show lifetimes, etc, and those would all be global wins instead of something rather niche.
I honestly didn't know that capability existed. Just to make sure I'm reading the right thing, is it the technique described in Equality proofs and deferred type errors: A compiler pearl [0]?
I have no training in programming language theory, so I can't give a good evaluation on how applicable this technique is to Rust. The first thing that jumps to mind is that I think it relies on Haskell's laziness to avoid evaluating the thunk (?) representing the type error if it isn't needed, but that's not to say that a different approach can't be found that doesn't require laziness (assuming I read the paper correctly).
That being said, given Rust provides types which defer borrowing checks to runtime (Cell/RefCell [1]), I think it may be possible to implement something similar to -fdefer-type-errors by e.g., wrapping all references in a Cell/RefCell and inserting appropriate function calls. I would guess the main concern there is fragmenting the Rust ecosystem into code that requires a hypothetical -fdefer-borrowck-errors flag and code that works with "standard" Rust, and tying that to optimization level has its own issues.
It's admittedly a bit different than what I had in mind when I first responded to ncmncm's comment (where I interpreted it as "pretend the borrowck errors didn't exist," as opposed to "use runtime checks as appropriate"), but it does make more sense.
Thanks for showing me something new!
[0]: https://www.microsoft.com/en-us/research/uploads/prod/2020/0...