When I compiled monodevelop, I compiled mono from a git source, though I assume that such a fundamental logic error would show itself previously.I guess I have to accept that reality is not logical hehe this episode is kind of strange to me.

nerdzero dexterously found the problem, and a bug report was filed #359

it had to do with nilable values that were not nil, regarded as true, no matter what the value inside actually is (which in this case was 'false')came about when using dynamic? (or Object? I'm not sure) from an external library. (I just forgot to state the result type of a boolean getter)

It comes down to assuming the action on a short cut notation conditional test ( for a nilable Object or nilable Dynamic type from a library)and/or not explicitly typing your getters .( not helped by the doc/wiki being silent on that exact case).If either the test was explicitly expanded, the item correctly cast or the getter was explicitly typed you would have been fine

any truth value that if accepts is probably susceptible here.

If its declared (explicitly or implicitly ) as nilable (Object/Dynamic) and not cast to the underlying type for an implicit truth test.

You can often see some light from problems such as these by looking at the generated C# code ( -kif option to compiler keeps the intermediate files around after compilation x.cobra -> x.cobra.cs) .

Alternatively and perhaps easier the ct_trace statement tells the compiler to emit some info about a variable as it goes through the various compiler stages, working out what it is, what interim type, final type, etc..

ct_tracehassubs

The output may be a little unintelligible to understand at first pass. (ctTrace)