Range of custom error codes for `clSetUserEventStatus`

For instance, in this case:
```
cl.EnqueueReadBuffer(..., ev0, &ev1);
cl.SetEventCallback(ev1, ()=>{ process_value(read_from_buffer); cl.SetUserEventStatus(ev2, ...); });
cl.EnqueueWriteBuffer(..., ev2, &ev3);
```
What if `process_value` throws a managed exception? It is a very bad idea to let it propagate through an unmanaged stack (this can cause memory leaks), so it is best to catch all exceptions in the callback.
But `cl.SetUserEventStatus` should be executed regardless, so that the rest of the queue would not freeze.

What status should be set, if an exception has been caught?
It should be a negative status, otherwise `cl.EnqueueWriteBuffer` (and possibly many more commands) would be redundantly executed.
But it's bad to reuse any known OpenCL error code here. It might be caught as returned `cl_int` value later, and viewed as a second, separate error.

I've so far been using `Int32.MinValue` (as a silent abort error code) and storing actual exception objects separately. So far it mostly worked fine.
But there is no telling if at some point some future version of core API or an extension would add this value as one of the known error codes, making my existing checks invalid.

Also had a case where an implementation didn't like something about `clSetUserEventStatus(ev, Int32.MinValue)` in a corner case, but this has been a while ago and I think they've already fixed it.

---

#### TL;DR

Is it possible to allocate a range of error codes, which would be explicitly valid for `clSetUserEventStatus`, but guaranteed to never be used by `OpenCL` implementation on its own?

Start with the clSetUserEventStatus specification and its error-status rules, then review the OpenCL core API behavior described in the example. Determine whether a reserved custom status range can be specified without conflicting with implementation errors, and document the resolved behavior or required specification change.

Written by the indexing model from the issue text.