`defer-errors-to-runtime` mode for gradual "unbreaking my code" in large refactor

I propose we enable a defer-errors-to-runtime[^1] feature for using fsharp compilation output even when there are type checking errors.

The F# way right now is to increase developer proficiency so any refactor is less than few minutes and always known to succeed, before getting feedback from the already running bits for the developer, this is great for making any F# developer a true jedi.

This is not great though when you tackle refactor and would like to at least try a bit of it for a specific focus area, without resorting to really crude things that can be done depending on the codebase (excluding many things, putting some #if in many places, etc.).

I think this is what the proponents of gradual typing peddle when they want to make our community of "like to rely on typechecker by default" (in same sense of "immutable by default", etc.) feel culprit of being in a type checker astronaut architect ivory tower, but I think it is possible to have the best of both, but in the F# way (not "on by default", only recommended if "you know what you are doing right?").

I remember hearing Gilad Bracha on topic of gradual typing, many years back, in context of vending dart, here is one such video: https://youtu.be/OGrXxGD-pZg?t=1416

Pros

getting earlier feedback, akin to REPL workflow
appeal for developers that come from dynamic typed platforms and who don't have full sense of appreciating type checker, have some hump to overcome to finding it is very good friend
more of "F# is for everyone, even if you don't know what public class Main { public static void main(string[] args) { means
increases the long term chance of having "F# the good parts" book written (there is no such thing as bad advertising)

Cons

some of the F# community frown upon "conscious opt-in" features that seem like "breaking the idioms of pure sheer safety of the language"
probably an XXL feature, that majority of F# users are currently living fine without
increases adoption of F# with growing share of community that uses it like true javascript programmer do, which would easily overthrow the rule of type checking theorists that conspire into making the whole world type checked by human made compilers already

Extra information

Estimated cost (XS, S, M, L, XL, XXL): XXL most likely, maybe less if @dsyme wants it badly?

Affidavit (please submit!)

Please tick these items by placing a cross in the box:

[x] This is not a question (e.g. like one you might ask on StackOverflow) and I have searched StackOverflow for discussions of this issue
[x] This is a language change and not purely a tooling change (e.g. compiler bug, editor support, warning/error messages, new warning, non-breaking optimisation) belonging to the compiler and tooling repository
[x] This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it
[x] I recklessly checked above item to "Make F# untyped", but "I don't make F# untyped" insert "but when I do meme" here
[x] I have searched both open and closed suggestions on this site and believe this is not a duplicate

Please tick all that apply:

[x] This is not a breaking change to the F# language design
[ ] I or my company would be willing to help implement and/or test this

For Readers

Please express your disgust for this idea with 👎, and argue that "F# is not for this" to your heart content in the textbox below this text.

[^1] credit to @drvink for pointing to haskell support for this, how it is done in "Equality proofs and deferred type errors A compiler pearl" paper

fsharp / fslang-suggestions