This is not the case right now. At the moment, 0 maps to false and !0 maps to true. See e.g. getrawtransaction's verbose argument handling.

EH, I have that the wrong way around, thanks.

Or not. What I meant here is:

false=0
true=1

E.g, the C++ mapping, not the bash mapping. As far as I know, we follow that everywhere?
If this wording is confusing, can you suggest another way.

I read it as "interpret 0 as false and 1 as true, and anything else is [??]".

I.e. if a user passes 2 or -1 to the new RPC command which maps as you said, how will it treat values beyond [0, 1]?

Am I misunderstanding?

I don't say anything about values besides 0 and 1 on purpose. Those may either map to 1, or to something else entirely (referring to "when bool has switched to multi-value"), or cause a failure.

Ohh I was reading this backwards. You're talking about when a bool becomes an int, and I about when an int is interpreted as a bool. I'll think on wording to make this obvious.

Re-reading this, I think I was simply not reading it properly. I think it looks fine as is.

Thanks for this! I vaguely presumed this was the case but never found anything explicitly stating it.

nit: s/block chain/blockchain