Probably need to release it as a patch so as not to need approval of the purity gatekeepers. People using it get an immediate boost in productivity as it enables exploration with no ultimate reduction in safety.
It doesn't matter whether it "works for certain inputs", or for any inputs. The point is to be able to direct attention to more immediately important algorithmic matters now, and then address borrow checker pedentism once actually difficult questions are resolved. The point is not to be able to ship code with borrow violations. It is hard for me to understand what is so difficult about this distinction.
The idea to use it during rapid prototyping is especially problematic, since that's the point where pernicious data access patterns will infect the entire design. Once the application "works, save from some double free bugs in weird testcases we don't expect in production, and which require a one month refactoring", the temptation to ship the flag into production will become overwhelming.
It could work by replacing any function with type errors (including those caused by type definitions) to panic on use, but otherwise still generate a binary. For type errors it is less useful than for lifetime errors because usually the problems of the former are very local while for the later it they are not.
But on the other hand
- Rust already has unsafe mode, which is exactly for allowing you to avoid some safety checks when you've decided you are smarter than the compiler
- this really is an example where the compiler isn't smart enough, as evidenced by the fact there are plans to make it work
So another "unsafe" type of marker that watered down the borrow checker would not be totally inconsistent with the language philosophy. It should work at the block or the file level, though - surely you wouldn't want to turn that off for all your code.