Say you have a class like this
public class Foo
{
public int Bar { get; set; } = 42;
}
ref
CS0206 A property or indexer may not be passed as an out or ref
parameter
get_Bar()
set_Bar()
var foo = new Foo();
foo.Bar++;
var foo = new Foo();
int tmp = foo.get_Bar();
tmp++;
foo.set_Bar(tmp);
ref
var foo = new Foo();
int tmp = foo.get_Bar();
DoSomething(ref tmp);
foo.set_Bar(tmp);
Like HansPassant said, this was a design decision that the C# team made when writing the C# specification, so you would have to ask one of them in order to get a proper answer.
If I was to hazard a guess, though, it would be that the amount of compiler magic to get passing a property with
ref would cause enough unobvious operations to happen behind the scenes as to make the solution undesirable. For example, how incrementing/decrementing a property works currently is as you say: the program assigns the value of the property's backing field to a temporary variable, performs the operation, and reassigns the result to the property. It's a straightforward process that doesn't incorporate any difficult concepts.
To do the same behind the scenes magic to pass a property with
ref, however, the process becomes a bit more involved. When a value type is passed by
ref, the actual value getting passed through the parameter is a pointer to the value type variable. To do this for a property, though, you would have to do something akin to your second example. That would result in the address of the temporary variable, not the property itself, to be passed to the method. That kind of behavior could cause some unforeseen and difficult to understand consequences for someone trying to manipulate the
ref parameter in certain ways.
So there's my guess, that the increment operator is simple to wrap because it only deals with values, whereas the
ref keyword is more complicated because it has to worry about scopes and memory addresses as well.
EDIT: Another reason that occurred to me, for a field, any manipulations inside the called method would be reflected on the field itself. These manipulations could be seen by other threads and such that accessed that field during the method's execution (best practices about concurrent field accessibility aside).
For a parameter, however, any changes that happen inside the method wouldn't be visible until the method returned and the value copied back over. This would lead to inconsistent behavior between fields and properties, the cause of which wouldn't be readily apparent.
(Personally, I think this is a more probable reason to not support
ref on properties.)