Current documentation leaves a lot of room for guessing and misinterpretation. There must be an explicit list of rules of what loadable modules must not do in any circumstances and guidelines on what they should do in case of certain failures (e.g. inability to allocate necessary resources). Quoting ZBXNEXT-3353.(2):

We should be explicit on what is and is not supported in modules:

• calling Zabbix internal functions (DB API, logging, locking, data structures, memory mgmt.), using macros except the ones specifically mentioned in module API;
• using Zabbix locks and/or attaching to shared memory segments used by Zabbix;
• linking against other libraries that might be used by Zabbix itself;
• loading and unloading other modules on behalf of Zabbix;
• exporting fake history data through other modules on behalf of Zabbix;
• compiler ABI requirements (does the module have to be compiled with the same compiler, release of the compiler as Zabbix);
• security considerations - running 3rd party code directly in Zabbix for which there might be exception policies set in SELinux, etc.
• accessing, modifying global variables, objects;
• accessing, modifying Zabbix DB;
• overriding signal handlers;
• subset of standard C, POSIX functions and syscalls (exit() is a clear example, but there are others);
• naming conventions;
• etc.