I think there are some differences:
- IR mode flashable to IT
- IR mode-only (not flashable to IT)
- IT mode-only (not flashable to IR)
- IT mode and when flashed with IR firmware, it only shows JBOD options
To know which one is which, you really do need to get the specific part numbers, not just the 'series' the chip belongs to. A slightly easier method is getting the part numbers listed for known good models from IBM/HP/Dell/QCT/SM etc. so you don't have to look up the chips.
How to know which one is which: this is indeed the problem, mainly because most manufacturers don't want to tell you, or 'enable' you to do any of this. They would much rather sell you brand new cards every time you want to change how you use your hardware. For a home lab that would make no sense at all. Since a lot of tech is essentially all the same, just different software or 'almost' the same but some parts omitted to save cost, with a little bit of work it is possible to get the hardware to do what we want it to do instead of what the manufacturer had in mind.
One of the reasons the IR-to-IT mode exists at all is because of SAN technologies needing powerful HBAs, so for a chip manufacturer it's much easier to just create one chip that can do whatever you need, and configure it as needed per product. Because most of those cards are essentially just embedded computers with their own CPU cores, RAM, persistent storage etc... they can be programmed to do all sorts of things.
Story time:
When ZFS became a viable option for commodity hardware (a combination of CPU power, RAM availability and cheap disks), people needed ways to connect a bunch of disks to a host, and a lot of the cheap PCIe-to-SATA cards just plain suck at their job. So a lot of time and energy went into looking for other ways to attach more disks, including expanders, SAS-to-SATA cables so you could SAS cards, and a comparison of HBA chipsets to figure out what they actually contain and how they actually work.
Those SAS cards became a popular target because of their availability on the second hand market. In the old days (let's say around the Blade hype) pretty much every server had to have a RAID card (HBA with a RAID controller to be correct), with cache DRAM, and a battery back-up. Those tended to be limited in features and performance, and server upgrades were still a sensible thing to do during their lifespan, so replacing all the cards in the entire fleet was a reasonable thing to do. Result: second hand market gets periodically flooded with SAS HBAs with RAID controllers. Because those tended to be 'slow' for ye olde RAID5/RAID6 (or some other dataloss-inducing RAID variety) they weren't worth much for their RAIDing features, so if you didn't need RAID, you essentially got a cheap HBA out of it.
Of course, the RAID controller would still mess with the disks, MITM the communication and hide what is actually happening so you never really know if the data you wrote is actually stored on-disk instead of mid-flight somewhere in a cache. That "we pretend to be a disk" thing that RAID controllers do is mostly for Windows because it has historically been pretty bad at heavy I/O things like storage and networking, so to get it to perform consistently you had to put a lot of the heavy lifting somewhere where the NT kernel couldn't see it (so: in the controller itself). Since it needed to be offloaded anyway (to save CPU cycles), emulating a disk probably seemed perfectly sensible at the time. ZFS, and most modern volume management systems, really do need to actually know what is up with the disks, because it relies on knowing where in the pipeline the writes and reads are to keep replication and integrity in check.
