Update syntax-method-call-on-string-literals.md

Incorporate the proposed wording into the rfc body.

rfcs/syntax-method-call-on-string-literals.md

@@ -29,11 +29,41 @@ Formally, the proposal is to move the `String` parser from `exp` to `prefixexp`:
   functioncall ::= prefixexp args | prefixexp `:´ Name args
 ```
 
-The recommendation is that we should keep statements starting with string tokens as illegal syntax, as it is too niche to support use cases with side-effecting functions.
+By itself, this change introduces an additional ambiguity because of the combination of non-significant whitespace and function calls with string literal as the first argument without the use of parentheses.
+
+Consider code like this:
+
+```
+local foo = bar
+("fmt"):format(...)
+```
+
+The grammar for this sequence suggests that the above is a function call to bar with a single string literal argument, "fmt", and format method is called on the result. This is a consequence of line endings not being significant, but humans don't read the code like this, and are likely to think that here, format is called on the string literal "fmt".
+
+Because of this, Lua 5.1 produces a syntax error whenever function call arguments start on the next line. Luau has the same error production rule; future versions of Lua remove this restriction but it's not clear that we want to remove this as this does help prevent errors.
+
+The grammar today also allows calling functions with string literals as their first (and only) argument without the use of parentheses; bar "fmt" is a function call. This is helpful when defining embedded domain-specific languages.
+
+By itself, this proposal thus would create a similar ambiguity in code like this:
+
+```
+local foo = bar
+"fmt":format(...)
+```
+
+While we could extend the line-based error check to include function literal arguments, this is not syntactically backwards compatible and as such may break existing code. A simpler and more conservative solution is to disallow string literal as the leading token of a new statement - there are no cases when this is valid today, so it's safe to limit this.
+
+Doing so would prohibit code like this:
+
+```
+"fmt":format(...)
+```
+
+However, there are no methods on the string object where code like this would be meaningful. As such, in addition to changing the grammar wrt string literals, we will add an extra ambiguity error whenever a statement starts with a string literal.
 
 ## Drawbacks
 
-Statements starting by parsing `prefixexp` will now allow string tokens to be parsed despite that the return values of the function calls are always discarded. This is a non-issue if we obey the recommendation to ban statements starting with string tokens.
+None known.
 
 ## Alternatives