I can't say but it could be that there are errors in the coding that causing an issue as well.
There cannot be a code error, or at least in the sense that it counts a 'failure'. Make3do.exe when it compiles a 3do file will output an error if there is a literal code error and no 3do will be generated. Running make3do.exe with -v also enables extra output to find errors if the code fails to compile (failed to make a 3do) -v added in commandline is very helpful then becasue every step make3do.exe takes when compiling will be listed and you can see every mesh it imports, links, and creates in a 3do compiling process.
Now in terms of
code optimization there could be possible avenues to make a mod more stable. There are ways you can make a mod using the same textures and meshes while having code that is different. One modder could group things differently together or call certain pieces first and others later in the code. Different combos like that could possibly make the final result 3do more or less stable. Maybe even doing lots of texture swaps or copy command could impact things. I've never really tried to make a non-optimized or unstable mod so always had neat code. For example, I never really got many complaints from users that my ICR mod crashed or was unstable (except low-end laptop pc's) and the mod was at the same levels as the Splash n' Go Gen6 19' mod with LOD 1 being several thousand tris.
My process of code for a mod usually goes in each section like:
1 - import all the meshes from my PAS scene(s) and define them with a name (i generally stick with one master PAS scene for interior and exterior, you can have a ton of separate ones if you want but when its all in one scene its way easier to edit when you need to visually align other parts)
2 - define the purpose of each imported mesh (for example if one mesh is meant to be a flap define all the flap code for it, at this point in the code that mesh would be 'functional' for its purpose. If a mesh is the exact same across the 4 different car makes for example I will literally just use that same mesh 4 times as one single mesh in the code and if the texture needs to be different do a texture swap or define it as the paint-job so it will be customizable to the player with the template for a mod.
3 - between the damaged and non-damaged state of a car all the areas on the non-damaged car you cannot see I reduce the poly count or simply delete it.
4 - group all similar defined meshes into their LOD groups and when I can get away wth it to reduce poly count even more just cram in EMPTY_MESH which is an empty mesh container that acts like a mesh. Further optimizations for any textures that are not paintable I define lower resolution textures for the meshes in LOD's farther away from the player. Like no reason to use a 2048x204 chassis texture for LOD 11, by then I'd just use like a 256x256 or even a 128x128.
5 - group all meshes and LOD groups into their respective sets, for example all the car body pieces as one group, wheels, etc etc, then I have one 'name' I cna call in the code in the future that includes all those pieces as 'one'
6 - with all the final grouped meshes I do the final definitions or outputs such as all the parts for one make and the car ID its for, then have the final make3do output command.
There are way more tricks that can be done to optimize a mod but I'd say this is the most common methods I do.
My process could be done very different as well. Another modder could import just one mesh, define its purpose, then move onto the next mesh, repeat etc etc, maybe group a few, import another mesh and definite its purpose, then move to doing some damage state code for the exterior, import an interior mesh and definite it, swap back to exterior mesh code, etc etc. That would be really messy but I have no idea if when compiling that process actually will result in the final 'product' of a 3do being more unstable or 'read' different by NR2003.
