Expand on the unresolved question of integer fallback.

Author: leoyvens

text/0000-default-type-parameter-fallback-take-two.md

@@ -566,7 +566,9 @@ fn foo<T=char>(t: T) { ... }
 fn main() { foo::<_>(22) }
 ```
 
-There is a concern with forward compatiblity of this approach presented about expanding the types a literal may be inferred to. Therefore it seems best to take option 1 or 4, as they future extensible to option 3. Any option other than 2 requires a phase-in period. Options 1 and 3 may change the behaviour of existing code, while option 4 may make existing code error. The consensus reached in the thread was for option 4, to be future-extensible but avoiding changing behaviour of existing code, is that still the consensus? 
+Any option other than 2 breaks existing code and will require some sort phase-in, options 1 and 3 may change the behaviour of existing code while option 4 may make existing code error. Options 1 is extensible to option 3 and option 4 is extensible to any other option. The consensus reached in the thread was for option 4, to be future-extensible but avoiding changing behaviour of existing code, is that still a consensus?
+
+The decision seems to come down between complete backwards compatibility with option 2 or complete forwards compatibility with option 4. If we were to take option 4 now is the best time, however it might break too much code to be viable and implementing it as a lint might be an implementation hazard.
 
 ### Terminology and syntax
 
@@ -606,5 +608,4 @@ fn main() {
 }
 ```
 
-We need to figure the design and implemetation of defaults in specialization chains. Probably we want to allow only one default for a parameter in a specialization chain.
-
+We need to figure the design and implementation of defaults in specialization chains. Probably we want to allow only one default for a parameter in a specialization chain.