Yes, it isn't trivial, and I don't think we'll use it internally as we don't know the id's when fighting monsters, so it has little practical use for anything Mafia does. This is purely a thing for scripts, mainly I suspect ones that interact with Manuel. For issues like tool gremlins it would make internal handling potentially more complex, as we'll have to handle monsters with multiple identical names, without any way to disambiguate them. The monster to int and int to monster functions will have to both be one to many relationships and return arrays for the scripter to then handle, and the int will not be a unique key, unless we totally change how we handle slimes, ed, dread bosses etc.
We currently translate the many possible names of the GamePro Dungeon mooks into the single monster they can represent by looking at the location we found them.
We COULD have 4 different ancient protector spirits - "ancient protector spirit (The Hidden Hospital)", for example - and translate into the correct type, similarly. Since they have different combat stats and drops, that would be useful for decorating the monster in the Relay Browser, as well as scripts.
Tool vs. non-tool gremlins cannot be discerned - and I am sure that is one reason why KoL itself will never give the monster ID on the fight page; it would allow third-party tools to recognize right away which kind it is, rather than having to stasis and wait for the "tell" for the non-tool variety. Therefore, it would be almost pointless for us to have two MonsterData for each gremlin, since we can't tell from the initial encounter which one you have found. Well, I suppose we could have two, and switch from one to the other when we recognize the message in combat...
I don't know what you mean by "slimes and dread bosses". We already have "slime1" through "slime5" and both Count Drunkula and Count Drunkula (Hard Mode). Which is to say, we already have multiple monsters for those.
I am thinking of whacking the method which is used by AdventureRequest which uses the responseText to get the "encounter" to use primarily the image, with tweaks as mentioned above, to get a MonsterData object. Aside from simplifying and speeding up the code, this would have only minor benefits for us - such as decorating protector spirits, as I mentioned - but it should be more maintainable, I hope.
Unfortunately, consult scripts are given a string, not a $monster. However, if we are a little smarter with deducing the MonsterData - and actually have unique monsters for the 4 protector spirits, for example - they'll also see an improvement.