Consider supporting optional operation parameters

We have frequently had requests to support optional parameters, but have pushed back because they could introduce ambiguity in function resolution.

However, with our current rules:
1) The unordered set of nonbinding parameter names must be unique, and
2) The ordered list of nonbinding parameter types must be unique

We could support making some parameters optional as a backward compatible change with the following resolution rules:
1) If the set of provided parameters exactly matches all parameters of an overload, then that overload is chosen
2) If the set of provided parameters matches all required and a subset of optional parameters of exactly one overload, then that overload is chosen

otherwise a 400 error

Questions:
1) Should we provide a set of rules so there is never any ambiguity (i.e., there does not exist a set of parameters for which one of the two rules above is not met) or specify that the service returns 400 if the request does not resolve to a single overload?
2) Should we define a default value for optional parameters? This would really just be documentation (the service wouldn't need you to tell it what the default value was in metadata). It could be useful in generating strongly typed function calls in languages with optional parameters (C++, C#,...) but there may not be a static default value that can be specified (i.e., current time, a computed value, etc.)