Your claim that 1.6.1 "completely disables #setting new values to the formal arguments" is...er...rather overstated. The mere #setting of things was broken in 1.6 but promptly fixed in 1.6.1. It's only this proxying of reference #setting that fails, and i was unaware that it ever used to work (though i take your word for it). This isn't something i ever used, much less relied upon.
That said, i guess i don't think passing macro args by name necessarily implies such complete proxying that it would proxy #set calls on those args. I consider that behavior to be rather surprising and over-complicated. I think few users would expect that #setting $result would set a value for $x and not even set a value for $result when velocimacro.context.localscope = false.
If we (return) down the path of supporting this, what happens when a user forgets that #myMacro will try reassign the value of anything he passes to it, and does this:
#myMacro( $foo.getBar() )
#myMacro( $x )
because the user knows $result was #set and that velocimacro.context.localscope = false. Or for that matter, users might simply be surprised to find that setting $result changed their previous value for $x, when they go to use it again. Such problems will become even more of an issue if the user is using a macro library that they did not write, as they will then have to be exceedingly careful that they don't pass references to macros unless they're sure they don't have further use for that reference, for who knows what the macro could do to their reference, even if velocimacro.context.localscope is true. Even the new #local directive proposal would not prevent such overriding, given the way you implemented your patch. There would be no way to protect a reference you passed to a macro except to do a wasted #set before it:
#set( $disposableX = $x )
#myMacro( $disposableX )
Honestly, i think i'd rather limit the proxying to the passing of args, not to the re-#setting of them. Then users don't have to worry about overriding the references being proxied when writing or using macros. The way it is is simpler to use and implement. Of course, on the other hand, breaking backwards compatibility is never ideal. Anyone else have thoughts?