When I was a junior developer working his first pro job in 1995, we didn't have Safari we had Netscape, and if we wanted to make the browser do something it couldn't do, like play a video or render a PDF, we wrote Netscape plugins against the NPAPI. I wouldn't say we were happy because the API was complex and fragile, but it was what we had. Come forward 16 years, and I'm dealing with NPAPI plugins again. It's only been in the last few years that interested parties have been actively improving to move the API to something that fits in better with a modern OS X browser environment.
Step one was a couple years ago, and involved removing the classic QuickDraw based drawing flavored plugin, replacing it with rendering into a browser provided Quartz context. This also tightened up the rules of when a plugin could draw--in response to a drawing event only--no more drawing while in a mouse tracking loop.
Second step was changing the event model, from one loosely modeled around the pre-Carbon event loop to one loosely modeled around the messages received by a Cocoa view. When Safari dropped support for the old event model between 5.0.1 and 5.1, a bunch of Internet Plugins just stopped loading.
Third step involves the use of Core Animation layers as a drawing environment instead of the Quartz context. Currently an optional drawing mode, the CALayer based model is much more powerful and convenient then the alternative, and I suspect will become the primary flavor of NPAPI plugins on "OS X". They might even allow for the sharing of code between iPhone apps, Mac applications and browser plugins if developers are careful to wrap them carefully—CALayers are the underlying drawing environment of both UIViews (iOS) and NSViews (OS X).
As Safari 5.1 is the default browser on 10.7, and it was recently pushed out to 10.6 users, there are probably a fair number of users searching for updates and tardy developers getting their mouse tracking code finalized. Including me.