I think I may have figured out what the crash is though.
I believe in (vmfloader) info_overlay, you are parsing StartU/EndU and StartV/EndV as int, instead of float.
While it's more common for them to usually be 1 or 0, in the actual format they are float, and in some of our maps
[Edit] Yep, that is absolutely what it is.
I also added a "hammuer" function to vmf_tweak (one of the source engine tools, that i don't think is publicly released other than in alien swarm maybe) which goes through everything that uses a model, and gives it a targetname, to make it easier on the import since without hammuer.lib source we cannot parse for anything.
As an aside, if it's unwilling for you sharing for example github access to it, would it be too much trouble for you to MOVE the "mapentity" stuff into the plugin itself, and out of the lib? ie: ask the plugin for the translation of all of the map classnames, for each of the loader.. instead of hardcoding the entity types into the lib.. (that is one of the things I would do if I had access lol)
Another thing that I would like to do, depending on how you load all the brush faces anyway, is to introduce part of the CSG process, so all intersecting brushfaces get chopped up to discard all of the parts of the solid that cannot be seen.. would save a lot of pre-processing time with going through a lot of old maps and clip + nodraw everywhere ;)
Especially large ones like this:
Note, that the grid here is a lot bigger than standard (65k/65k) and this map fills up almost all of the normal source engine map size, horizontally anyway. lol. (we had/have a lot of large maps in TI, and our version of the engine/hammer increases a lot of limits..which is good for making stuff for unreal as well :))