I don’t agree with your arguments. Sure, you can call const in C a “hint,” but a misleading hint is worse than none. If you need to cast away const to work with your own internal data structures, that’s a strong sign the structure doesn’t really match how it’s being used.
The `SHARED_WRITE` macros don’t feel relevant here. They deal with shared memory for Windows handles (something those handles weren’t designed for) so they need extra complexity and supporting infrastructure. Their use is also more widespread, so various parts of code need to deal with them. I get why const might be helpful in that case.
But the user handle table is much simpler. Its access is well-contained and clear, and I don’t see the point in trying to be “protective” against ourselves. Take your `handle_to_entry` function: it has just five callers, and two already treat the result as mutable (even if indirectly). So why not just return a non-const pointer? The others can still store its result in a const variable. And all of them are already closely tied to the table’s internals, so whoever touches them is going to understand the consequences anyway.
(Also, on top of that series, it might be a good idea to move `get_user_full_handle` out of the server, which would leave only half of its callers treating the result as immutable.)
That said, you seem to feel strongly about it, and I wouldn't feel honest approving it as-is. My approval isn't required anyway.