Normally, you are right, but I’m doing this on purpose to illustrate what I believe to be a general bug. The fact that mFoobar is used inside the Foobar Getter and Setter may (or may not) be relevant. I’ll do another test to see.
Um, it seems extremely relevant. You’ve got 2 public methods initializing the same property. Order of operation (which is undefined, and may easily change from one release to the next, or even one save of the project to the next) comes into play as far as which value is assigned.
Note that your project is auto-saved when you run it, which could account for the differences you’ve seen between runs of the same project.
Also - for a computed property, there is no value allowed in the Inspector Behavior dialog box - you can set a value for regular properties, but not computed properties. However, if you check the box for a computed property, then you can set a value on the instance itself using the window / inspector.
To be absolutely 100% pedantic here, so there can be no confusion. In 29724, the first example I submitted “prop2” shows a situation where there can only be two logical outcomes:
Foobar=999 and mFoobar=999 (if the Foobar setter happened after the mFoobar setter)
Foobar=37 and mFoobar=37 (if the Foobar setter happened before the mFoobar setter)
But what we see is
Foobar=0 and mFoobar = 0
THAT is the bug. There is no logical way that a Zero can be getting in here. Please focus on this issue and ONLY this issue in your analysis. Other topics (such as the order of operation) are interesting but not relevant.