There are a few TODOs in the cl_khr_semaphore asciidoc sources that would be good to resolve before the extension is final:

1. TODO: This error code is already allocated. Use -1141 instead?
   • I think this is a stale comment that can be removed. Error code value -1142 is properly assigned to CL_INVALID_SEMAPHORE_KHR.
2. TODO: Do we want the same "all devices in the context" behavior if CL_DEVICE_HANDLE_LIST_KHR is not specified?
   • I think this is a stale comment too, and that it can be removed. The default behavior when the device handle list is not specified is properly described.
3. TODO: We don't need an enum assigned for CL_DEVICE_HANDLE_LIST_END_KHR and should just use 0.
   • I think this is a stale comment that can be removed, since CL_DEVICE_HANDLE_LIST_END_KHR now has the value 0.
   • Debatably we could remove these enum names entirely and just use the value 0 instead, though we do define CL_DEVICE_PARTITION_BY_COUNTS_LIST_END, so we may as well keep it.
4. TODO: Do we need to define CL_DEVICE_HANDLE_LIST here or should it be in the external semaphore spec instead?
   • This one is potentially interesting. Do we want to support creating (NOT importing!) a semaphore associated with a specific device?
   • Said another way, should it be an error to specify a device handle list without also specifying an external semaphore handle?
   • Recall we specified that it is an error to specify a device handle list for a memory object without also specifying an external memory handle with cl_khr_external_memory: add error when CL_DEVICE_HANDLE_LIST_KHR is specified without an external memory handle #922 (related issue: Behaviour of clCreate{Buffer,Image}WithProperties when CL_DEVICE_HANDLE_LIST_KHR is provided but no external memory handle is #916).