Addressing a few points from above:
>>Some return values say: CasResult<ulong> (Cas result of bool). What is "Cas result of bool"?
Changed to "`ulong` the result of the value decremented by the offset (if the default value has not been stored, it will be the default value)". This will be included in the 1.3.2 release.
>>Other return values say: IMutateOperationResult (Mutate operation result). Is the same operation really expected to return drastically different object types?
Yes, their are two 'forms' of operations exposed by the 1.X version of the SDK: one's that return the explicit result of the operation (true/false/integer/etc) and one's that return a 'richer' object which includes the StatusCode, whether or not an exception occurred, the explicit result of the operation, etc. The former have a naming convention with that matches the operation (e.g. Increment, Decrement, etc) and the former are named Execute[Operation] (e.g. ExecuteIncrement, ExecuteGet, etc). The former were added after the fact so that they wouldn't change the interface of the API, which would be breaking changes for clients, while adding much needed 'meta-info' about the operation's status.
>>Some examples have "var casv = client.GetWithCas("inventory");" before performing the increment. Is it necessary to get the CAS id before performing this type of increment? Is it necessary to supply the CAS id for this type of increment?
Yes, that was how the API was designed. We will investigate more intuitive means of using CAS in 2.X version of the SDK.