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.
How is the hint misleading? If you consider it as a hint that something is constant, then yes, because it's not what it means and we're then using it wrong everywhere. It's not a hint but a guard to make sure a pointer cannot directly be used to mutate what it's being pointed to.
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.
I don't see any difference with them, and like I described above I think it's even more important to keep it for user handle entries which lack proper data consistency outside of the alloc/free calls. For the sake of consistency I would rather remove const everywhere or keep it everywhere. Otherwise, having some of the use case non-const cascades up to the shared_session pointer, and raises genuine interrogation and suspicion over why some pointers are deemed to be const qualified and some aren't.
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.
Well I don't know what's required, it would be much easier with some explicit feedback but as usual my only option here is to take guesses. I have the strong feeling that even if not a requirement, an approval from a trusted developer is a strong incentive to get things merged. Similarly, a comment from a trusted developer questioning part of the code, is a strong incentive not to get things merged until things get settled.