I don't know which way to vote on this one.

Therefore, interpreting a challenge asking for a return value as "return through parameter" is creating a local code golf dialect of the language

I see this Meta discussion as establishing defaults. Any challenge is free to override the defaults and insist on only a return value, or only output to STDOUT, or only output containing no vowels, or whatever the challenge author decides to impose. For challenges where the author does not impose it, I don't see a reason to favour one output method over another.

Where a challenge does not explicitly require a return value, using an approach that is built into the language (modification of an input argument) does not seem like creating a new dialect.

Not all languages support pass by reference

I don't see this as a reason to prevent its use by languages that do support it. There are many ways that languages differ and restricting the particular advantages that each language has seems to remove the benefit of allowing submissions in different languages.

Some languages separate subroutines (do not return a value) from functions (returns a value)

In such a language I would see a subroutine that modifies an input argument as a valid submission, unless the challenge explicitly requires a function. I agree that a challenge that requires a function rules out a submission in the form of a subroutine, and that restricts those languages that separate subroutines and functions, but I don't see that as a reason to restrict languages that do allow modification of function arguments.

In common usage, "function" is often used to include functions that can have side effects. If a challenge author wanted to exclude this, I would expect them to use a more specific term, such as "pure function" or "function with no side effects".

• Assuming that things like memory allocation are handled by the caller might give contributions an unfair advantage

I'm not sure how to interpret this. If a fixed size input argument (such as a 32 bit integer) is modified, there is no need for memory allocation as it already exists. If a short string is received as an input argument, and is modified to become much longer, I wouldn't expect submissions in most languages to have to do any explicit (byte costing) memory allocation regardless of whether the output is by return value or modification of input argument.

It sounds like the advantage here is probably restricted to some special cases. If so, that seems like a reason to set a default for such specific cases rather than ban all modification of input arguments. I'm not sure if I've correctly understood this last bullet point though.