Yes it is truly obvious that the compiler creates a backing variable for the auto property. Obviously, it has to have somewhere to put the state exposed by the auto property but it hides the backing variale from normal view because it wants the property to appear like a field.
Ignoring such implementation details, the auto property behaves like a field. It stores state and is getable and settable by direct assignment, without using getter and setter semantics. To a C# programmer an auto property is basically a field.
Given that, I don't see the justification for your comment "Therefore, semantically, auto-properties must be treated the same way as operations...". It looks like a field, it smells like a field, it quacks like a field, it should be treated as a field.
Modeling state is secondary to what I do, which is write software in C#. Eschewing auto properties just because EA can't handle them would let the tail very much wag the dog.
C# programmers use auto properties as a matter of course, and think of them as glorified fields. I'd be very surprised if you could find a single C# program of any size written in the last 4 years that does not use them. (There are some other reasons for using them, particularly in WPF view models, that I won't go into here.)
If SPARX are unwilling to accommodate auto properties in EA, then I clearly have to accept that. But it does make EA much less attractive to me as a modeling tool. I imagine the same is true of most C# programmers when they discover EA can't model auto properties in an intuitive way.
I like EA and use it a lot, but this issue is a real pain in the neck...
