Should values given to C through API "handles" be mutable?

I feel like I've sort of answered my own question.

Whatever the C++ API does, the "C friendly" API should probably not have any mutators. If people have an iteration that they're particularly worried about the consequences of generating tons of superfluous handles, they should probably escape out from C to Rebol and do that iteration in Rebol code.

I think this is just going to have to be the performance balance. People writing repetitive procedures called into Rebol from C should probably register their C-part as a FUNCTION! and do their loop part as a string of Rebol code... OR... get comfortable with releasing handles manually... OR... not care and let the FRAME! clean it up... OR... use C++ and have it taken care of automatically... OR... use the rebRing() concept (rebTemp()?).

Not sure where this leaves reb_value vs REBVAL*. Windows programming involves a lot of HWND and HPROCESS and other H-prefixed stuff where you understand that you're responsible for it, while it's not expressed as a literal pointer. If we're going to be talking about lifetime management being in the client's consciousness, I'm not sure a name like reb_value that looks to be passed by value fits in. Also, one benefit of being forthcoming about it being a legitimate REBVAL* is that any code linked to the internal API would see the type as non-opaque and yet be able to use it with the same libRebol functions.

Anyway, guess I'm just saying there are enough options here to not sweat it, and indeed to say that NULL pointers mean what Ren-C calls a NULL. I guess we'll have to wait to see if libRed tries to introduce any ways to mutate cells in the ring, but under their current direction it doesn't seem likely that would happen.

To put it another way: If libRed ever allowed mutating operations, the by-value look of red_value being passed would seem a lie. When you pass a C function something that doesn't look like it's being passed by pointer, you semantically assume you got your own copy. The only way to make that work when your underlying implementation is a void pointer to a cell in a ring would be if copying meant nothing, e.g. immutability.