That's orthogonal to the variable size issue. Sure, mapping the session in chunks is possible, but it's just a different approach and doesn't change much: instead of refcounting the session you'd need to add some logic to keep chunks around and map new ones.
Sure, that's orthogonal.
The server currently doesn't have any mean to know which objects are being cached / read by the clients, it can only invalidate them by changing their IDs, but other than that have no way to safely merge them together [*]. This would require refcounting of the objects on the server side, track object open/close operations, and release them as well when the process dies violently.
We could just never release such objects to the global pool and keep their free list separated. Again, that's not a concern at this point, but it's not a hard problem if needed.
TBH, I think you're exaggerating that complexity.
Writing a basic heap is easy, but writing a good one, robust to fragmentation for instance, not so much.
Do we need that here?