I am using IPE 2.26 on win7. First time I loaded it I thought it was broken. It takes half a minute before I get confirmation that I even opened the program.
So I take it 3.2 is not necessarily faster.
What was "broke" was that MPLAB 8 isn't cross platform. So while they buggered a few pooches in the process, they didn't try to fix something that wasn't broken by making X. (They just didn't make it that great; and worse, they dropped support/development of 8 partway through the process of integrating PK3). Most of the PK3 issues seem to be created by X/IPE. The device works perfectly with 8, out of the box AFAIK, except for the faulty/unfinished implementation of P2G in 8. If you use Linux or Max, X is probably fantastic.
If they had finished PK3 implementation in 8 and/or when they finish polishing X, PK3 would possibly be fine, depending on your point of view/OS. As it stands, there are potential issues with PK3 across the board, because you have to use buggy X/IPE in order to use all the features of the PK3, but the PK3 might not even work with X without some backdoor tweaking requiring 8. Maybe someone will finally explain how to get a PK3 working without using 8. AFAIK for now, you might in fact need to use 8 in order to make a given PK3 work with X, go figure. (That, or send back your PK3 for a new one that hopefully has the right FW suite pre-installed).
All that said, the improvements of PK3 vs PK2 are pretty minimal* and don't extend much beyond IDE integration (basically auto-flash after a recompile, and ability to read/modify/write registers within IDE, which is a minimal improvement. The former is nice, but the latter still requires opening a different window; PK2 standalone is just as handy, there, plus more handy for some uses), much faster flash speed of 32 bit devices, and the debugger. They could continue to update the device list for the PK2, if they weren't dicks. I think Richard Head was never fired and instead got a promotion. It might be a good idea if PK3 and X/IPE were polished. But forcing users who might otherwise be fine without a debugger to use PK3 over PK2 for new devices is putting a fat ugly foot forward. It's forcing people to switch, so that if they don't gag over the bloat of X and the undocumented (or poorly documented) hoops to get the PK3 to work, they will simply fall in love with the integration with the IDE, the debugger, and the faster flashing (of higher end devices; it is NOT significantly faster with 8 bit devices, at all; in fact, sometimes it's slower).
*IPE has a lot of cool features for production use (theoretically). You can limit the number of flashes. It will track the number of good and failed flash attempts. You can tag devices with a random or sequential serial number using one of more register locations, apparently. I say apparently, because 20 minutes of fiddling, and I can't figure out how to get that to work, and I gave up because it takes approximately 3-4 times as long to flash an 8 bit chip on my machine using IPE + PK3, anway, than it does when using PK3 with 8 or in P2G mode or compared to a PK2 - which these all take approximately the same time. So I wouldn't use IPE for batch programming, anyway. At least not on my i5 Win7 machine with the PK3. It is hideously slow, and the delay is not just in the software/interface, which is miserable. Even when the device finally starts to flash/verify, that takes much longer than normal.