/database, /regex, and /generator each have a var named _binobj which is used to hold a reference to an opaque object unique to each type. I had the idea that byondapi could leverage that type of opaque reference to allow developers of external libraries to wrap arbitrary data structures in a mostly unambiguous way.

The kind of function I had in mind would look something like this:
bool ByondValue_NewBinObj(void* ptr, void* dtor, CByondValue* out)

This function would create a _binobj-like BYOND value which, when garbage collected, calls dtor with ptr as its first argument (or, possibly, if dtor is null, just frees ptr)

This would probably need to come with a corresponding function to read a pointer from an opaque reference type. Something like:
bool ByondValue_ReadBinObj(const CByondValue* value, void* out)

This function would return false if value is not a _binobj or was not created by byondapi. Otherwise, it sets out to the pointer wrapped by value.

While in most cases, the lack of such functionality could easily be worked around by simply returning a string handle to the desired binary object, there are certain use cases in which doing so is inconvenient, even to the point of infeasability.

One particular use case (mine specifically) is integrating an external scripting language which can return types that cannot be unambiguously represented in BYOND. In such languages, these values could be returned on their own, or inside of list-like data structures at an arbitrary depth. In these situations, if you were to attempt to represent these types as string handles, users could return strings that would be misinterpreted as string handles (whether or not they are valid).