You are right that update shouldn't have broken it for you either, and looking at it I don't see why it would break it for you. You have no other PwmOut objects at the same time? If not I can later look at it more in depth, not now though :).
Btw it is possible to handle both scenarios, using a dynamic prescaler. And that is exactly what that update added. And also what FastPWM uses for 16-bit timers (on 32-bit timers it is a waste of cpu cycles to calculate prescalers: the NXP 32-bit timers can make periods up to something like 10,000 years on the LPC11u24, longer on the LPC1768). From all use cases with PWM at high speeds, yours is the one which profits least from FastPWM (all other supported devices have increased resolution), still it might be useful since it allows you to change your period with clock cycle accuracy, instead of microsecond accuracy.
Of course that doesn't fix the library, which also should be done, when figured out what the actual issue is :P.
A while ago I wrote some code for a booster circuit that drives PIO0_8 at 500kHz with a varying duty cycle. The code I used (simplified for clarity) is as follows:
Today I received a nasty surprise when I tried to revisit this code using the latest mbed library revision. For some reason, I was no longer getting the voltage I was expecting. On closer inspection with an oscilloscope, I found that PIO0_8 is no longer running at 500kHz, but around 33kHz. At this point I haven't checked the past library versions to find out where it broke, but it is definitely broken. Attached is a picture of the waveform I get when I run the attached code with mbed library revision 83: