Don't see an unsolvable problem here, it's only a matter of design:
A file in a Unix file system does not get deleted as long as there's a hard link to it, only when the last 'hard link' is removed, the file is actually deleted. (or 'unlink()'ed ;-)
That's the bookkeeper's responsibility.
True, although you'd need to implement some form of reference counting for handles, and because of the way Osiris works internally, handles can be retained in "intermediate databases", even though you don't save them in an actual DB.
Also, there are hundreds of ways to leak handles (some script stuffs them into a DB and forgets about it, etc.) which would mean that you (as a scripter/designer) will have to do extra bookkeeping as well to make sure you dispose of all handles properly. The code would have to handle additonal states for items/characters/objects (eg. what if an object is teleported after it is destroyed but its handle is still valid? etc.) Based on my experience with managed languages (C#, Java), tracking down leaks is hard as hell, even when you have some debugging tools. It would also cause progressively larger savegames and loading/saving times as the game progresses.
I'd say the 64-bit handles are a much simpler solution to this problem than refcounting would be.
