From 5.9 Event Objects
The execution status of an enqueued command at any given point in time can be CL_QUEUED (command has been enqueued in the command-queue), CL_SUBMITTED (enqueued command has been submitted by the host to the device associated with the command-queue), CL_RUNNING (device is currently executing this command), CL_COMPLETE (command has successfully completed) or the appropriate error code if the command was abnormally terminated (this may be caused by a bad memory access etc.).
The function cl_event clCreateUserEvent (cl_context context, cl_int *errcode_ret)
...
The execution status of the user event object created is set to CL_SUBMITTED.
The function cl_int clSetUserEventStatus (cl_event event, cl_int execution_status) sets the execution status of a user event object.
If user created event is set to CL_SUBMITTED, then what if anything should be set for CL_QUEUED? I'm under the impression that the order of those events is strictly linear, i.e., CL_QUEUED -> CL_SUBMITTED -> CL_RUNNING -> CL_COMPLETED, possibly terminating with an error at any point. So what happens if someone queries CL_QUEUED? It doesn't make sense to set the status (which also records the time?) of CL_QUEUED after CL_SUBMITTED has been set.

Also, if a function is passed a list of events to wait on, should that function internally retain each event in that list and then release them before returning?