I think a good way to handle this is to pass the arguments back to the function. This is very similar to what Gabriel already proposed, but when the RHS is more complex it will be cleaner. Unlike Leonid's method it does not rely on Symbol evaluation and will therefore work inside held constructs.

Very nice, +1. The reason I did not go this way is that you will have to hunt down all occurrences of z and replace them with z/.Automatic -> y, and if you forget some, there isn't any easy way to see that, so for functions with more complex / larger bodies this will be harder to maintain. But for a simple function, this is quite elegant.
–
Leonid ShifrinDec 4 '12 at 23:03

@Leonid yes, you are right, but I had the vision of Options in front of my eyes :) Of course that involves a Module and a local variable to replace z everywhere, as you have pointed out.
–
István ZacharDec 5 '12 at 20:36

ohhhhh didn't realize this works. Any thoughts on why Mathematica color codes the yy in the block red? Seems to think it is not used. Man this is soooo sweet you get the R behavior as well, you can make the default arguments expressions like 1/yy etc. Thanks for this!
–
GabrielDec 4 '12 at 21:01

@Gabriel Well, a number of constructive uses of nested scoping constructs formally create variable collisions. Those who use that stuff know exactly how they are resolved, but it makes sense for the highlighter to generally warn about those. In this particular case, the way it works is that Block does localize the special variable created by Module, not the top-level yy, so things are fine.
–
Leonid ShifrinDec 4 '12 at 21:06

Mathematica is a registered trademark of Wolfram Research, Inc. While the mark is used herein with the limited permission of Wolfram Research, Stack Exchange and this site disclaim all affiliation therewith.