Although this is one solution, the issue then becomes one of interrupt latency. The question would then become how long the interrupts would remain off and it would depend on how the function is written. If this is the route taken, it would probably be best to include in the documentation somewhere that interrupts need to be turned off at the application level (in the user sketch) if you’re using another interrupt driven SPI device. Otherwise, its quite difficult to trace the cause of the hang.
The main issue that I saw was that since the SPI accesses to the Wiznet were not protected from external interrupts, it basically means that the ethernet shield can’t share the SPI bus with interrupt driven SPI devices.
In most embedded designs, the interrupts would be turned off only during the actual IC accesses since this would usually be short. This prevents locking out other peripherals that need interrupt servicing for long periods of time.
I can understand that there’s probably some resistance to modifying the code to fix this issue. However this problem will become much more pronounced if the Arduino moves to integrate the Wiznet Ethernet IC on the actual MCU board. Then, it won’t be a matter of shield compatibility but a matter of the Arduino Ethernet board being compatible with other devices.
So my point was that a lot of this can be avoided by simply protecting the SPI accesses to the Wiznet from external interrupts. My advice would be the same for other interrupt driven SPI devices, too. The SPI bus is meant to be shared and so everyone needs to play nicely on it.