Just some thing to make life easier.

I dont know why do you need it in 1.12 all the different types of entities are it's own entity.

You can also dupe items if a zombie picks up an item

@Buuz135

The need for this should be relatively obvious. Not all the data of a mob is stored just in its entity ID. A primary example (possibly only) is the villager. Let's say I find a villager and get him offering the exact trade I want. I want to make copies of him, exactly as he is, so that I can do that trade with each duplicate. The trading data are not included in the entity ID. There's no guarantee I'll even get the same type of villager, let alone the trades.

Without an option for exact, this workflow is not possible, and is one of the reasons the source mod which IF is recreating had the option (among others, like the fact skeleton and wither-skeleton used to be just a metadata difference, which you point out is solved by the ID separation).

Hrm. Point taken on the dupe issue. I'm not certain how inventory is handled on mobs. However, I assume (I know, I know... ;) ) that this is stored in the NBT under a common set of flags, such as <key_for_chestarmor>: or :.

Under this assumption, you could make this a configuration option:
exact_allowed: true/false
exact_allow_items: true/false.

With exact_allowed: false, the option for exact is removed from game, for mod pack authors who don't want to deal with it at all.

With exact_allowed:true but exact_allow_items:false, however, these common NBT holders are ignored in the duplication process, while all else remains the same. This allows modpack owners to decide if they want the dupe allowed or not.

This is admittedly taking some liberties with how zombies and other mobs inventories are handled. But would this sort of approach make the idea salvageable?

er, that second example should have been inventoryslot:item_info. Not sure why it got filtered.