I'm sorry that I can't answer this question with solid knowledge, but just a guess and the backstory behind this guess. Feel free to ignore the answer if you only care about hard source facts.

I expect the drivers are supposed to behave identically, and you shouldn't expect any performance difference.

With the advent of Windows 95, there was a revolution in the way the OS, the hardware and drivers worked. The classic model works like this

1. You choose resources for a card you want to install
2. You set the jumpers/DIP switches for all options that are configured in hardware (if any)
3. You install the card
4. You run a configuration tool that configures an EEPROM for all options that are software configurable and non-volatile (if any)
5. You install a boot-time configuration tool set configures all software configurable options that are volatile (if any)
6. You tell the operating system to load a specific driver.
7. You tell the driver how the card is configured. User-friendly drivers might auto-detect some configuration settings.
8. The driver verifies whether the given options look correct, and might auto-detect further options.

Note how many lines start with "you". The new model is the plug-and-play model:

1. You install a card
2. The operating system assigns resources to the card to make it usable
3. The operating system locates a driver that matches the card ID
4. The operating system tells the driver about the resources assigned by the operating system

For non-plug-and-play ISA cards, the plug-and-play model doesn't fully work, nevertheless, Microsoft pushed all hardware vendors to write "plug-and-play model drivers". These drivers do not initialize any hardware until told so by the operating system, which is in contrast to classic drivers, that initialize the hardware when the driver is loaded. As the operating system is managing all the resources in the plug-and-play mode, the operating system needs to be aware of all resources (ports and IRQs) of the card, so even for cards that are jumper-configured, the plug-and-play model means that the operating system is supposed to tell the driver about all resources of the component, while in the classic model, the driver might be able to read some configuration information from the card, so that the I/O port is enough for the driver to read the IRQ. And that's how classic 3com drivers worked: You tell the driver the port, and the driver uses the port I/O interface to ask the card for the IRQ. The driver does not need you to specify the IRQ.

So the "ISA mode" driver is likely a driver that manages the IRQ by itself, without bothering about the operating system, whereas the "PnP mode" driver is how Microsoft intended Windows 95 to be written. As you observed, the with the ISA mode driver, the IRQ is not visible in the device manager, so Windows is unable to know that the IRQ is in use, and might assign the same IRQ to some ISA Plug and Play sound card, e.g. the mostly unused CD-ROM interface of some Soundblaster PnP card. This is obviously a bad thing. If you have a PnP/PCI BIOS, you can set some IRQs to "legacy ISA", and I expect Windows 95 to obey that setting. With a classic ISA BIOS, you need to find some way to reserve the IRQ in Windows 95 to make sure it does not get allocated to PnP devices. This obviously only is a concern if you use PnP devices. On the other hand, the PnP mode driver has the IRQ registered in the OS, so the hardware resource management of the operating system can correctly respect the resources used by the 3com card.

In the end, it means that using the "PnP" driver is preferred because it correctly interacts with the PnP resource manager of the operating system. On the other hand, it also means that using the PnP driver puts a third entity into the equation besides you and the driver: The PnP resource manager. If you work on a fully manually configured system, the PnP manager is not needed and does not interfere with you if everything goes well, but might cause trouble if something goes wrong. Using the "ISA mode" driver reduces the complexity by circumventing the PnP manager, and thus is less error prone in situations where PnP resource management is not needed. The Windows 3.11 3com driver only exists in an "ISA mode" edition, because Windows 3.11 lacks a PnP resource manager.

Thank you very much for that very comprehensive answer. I also vote for your idea that the Isa driver „internally“ will use the irq without windows to know.

Thanks again