I looked at the codes high and low, as hard as I can, but my mind can't compute. How?

See attachment below.

[attachment=27854:capture.png]

No. It's just returning the value, nothing else was done. The value is shown in the top right corner in the Auto view.

I noticed it's a UnityVS project. The debugger is not 100% trustworthy in that case... Maybe add some Debug.Log calls and double check that Unity is executing the latest version of that code?

Ok I guess. I've reported this error to the UnityVS team. I was told this is a possible race condition, where the variables are not refreshed/updated long enough while the debugger is attached to Unity running on different threads. Maybe it's a rare corner case scenario, who knows?

I'm seconding the guess that something was out of date. It is easy to make changes that don't get detected and trigger a recompile.

But without seeing your code, it also COULD be a race condition.

Maybe it's a rare corner case scenario, who knows?

Possibly, Unity makes adding asynchronous behavior -- and therefore bugs from race conditions -- easy to implement.

While some of their tasks work well on the side, for instance co-routines are not distinct threads, if you are setting or modifying the values in any way that could lead to parallel behavior you need to properly manage it values with locks.

If you are taking advantage of asynchronous processing, and especially if you are doing any threading yourself, you need to understand all cases where systems might interact between processes.

The built-in stuff is generally cooperative and does not interrupt each other (except where documented), but if you're doing any multiprocessing yourself, beware, and ensure you follow proper locking semantics.

Looking at the value for YEnd (in the upper right of the image), it is -0.470853031f and yMin.position.y is 0.3. 0.3 > -0.470853031.