(this needs 16bit adjustments)

Just use -1 instead of 0xFF…FF.

I don't think this will exit on next == MUTEX_LOCKED.

Doesn't _mutex_lock() catch that case before calling thread_add_to_list()?

I would do

static inline void list_add(list_node_t **node, list_node_t *new_node) {
    if (*node == NULL) {
        *node = new_node;
    }
    else {
        new_node->next = node->next;
        node->next = new_node;
    }
}

To make the API more consistent with clist_node_t (empty list is NULL).

edit: fixed dereferencialization in if statement.

Somehow I dislike replacing two lines with four for API consistency.

Then how is an empty list represented in your version?

As pointer to the first element. edit misread.

A list is represented as pointer to the first element, and that struct is conveniently the same as that of a list node. So if the list is empty, the list node representing the list has a NULL next ptr.

So you always need one extra element in memory? That's not ideal either ;-)

Ah okay. I did not read it that way. So an empty list is still a NULL pointer in your version? Wouldn't this just require the user to add the check I introduced above anyways i.e. just put the code outside the API?

Well, every list is a "list_node_t". That struct just happens to only contain a pointer. If there are elements, that pointer points to the first element, if not, it is NULL.
The add function inserts an element after another. If the root node of the list is specified as first parameter, the new object will be the new head of the list.
The remove_head function removes the first and returns it, if any.
No further checks needed.

This function is never called.

I don't have the time to understand the full PR, I'm just a bit confused why you introduce a new list implementation and use only the "remove head" function.

I thought these underscores were forbidden?

shouldn't you use list_add() here, so you don't break the list? So if the current list->next is somewhere in the middle of the list, and we run the line above, the items that have been pointed to by list->next before are dropped from the list, right?

ups, overlooked l119, so everything should be ok. You might want to more l119 out of the loop and remove l114 though.

we don't want the struct name here, or am I missing something?

yes, I missed the next line. sorry (: