Do Not Require Polyfills

I'll try to keep it as simple as it sound, polyfills should never be a dependency and here is why:

Do Not Confuse Polyfills With Libraries

If you are using any utility library that brings you something similar to requestAnimationFrame under a different namespace that is not the window or the global object, that is not a polyfill but rather a library you have dependencies based on, and this is OK!

Polyfills Do Not Want Maintenance

Indeed, polyfills are scripts usually placed upfront the main application that should be removed when time is right, which means ASAP, without requiring indirectly any update, upgrade, or change from your own module.

Polyfills Aren't Virtually Needed

You don't want to require('latest-browser-or-nodejs'); in your code, because that is pointless, no matter if you use a UMD or a browserify approach, no module should contain a polyfill and here is why:

Global Pollution

Yes, polyfills are usually greedy because being polyfills they fill the environment gap, where the environment is usually not confined in your own closure.

Deadly Obtrusive

If your module defines its logic behind some feature detection and including another module could change this, you are basically dropping an undesired bomb in your system you were not aware of the moment your module acted as it should ... as module, library, whatever it is, that didn't include a bloody obtrusive AMD that changed everything the module knows before that ... I mean, the moment your module is defined, that's the env you expect.

Always Upfront!

Polyfills should have the exclusive position on top of anything you are developing because the day you won't need them you'll simply drop them and everything else will keep working lighter and faster.
Making your polyfill usable as a module won't benefit anything based on it for the simple reason that such modules won't be portable without a potentially not needed/necessary anymore environment normalizer, and need at that time extra maintenance form something assumed to work as that in such environment.

Delegate Dependencies

If your module depends on some polyfill just say so ... any other module that depends on your one might need or rely same polyfill too so don't make such polyfill your own choice .. and once again, if it does not change globally the behavior, it's NOT a polyfill ... in such case, feel free to include it!

What About browserify ?

It's OK to publish modules to npm or bower so that it's possible to create a build task that will include polyfills in the right order, if needed, using require('es5-shim') and require('dom4') and others upfront.
However, if you did the mistake to wrap your polyfill inside an UMD and the define library is around, being the inclusion of modules completely arbitrary in terms of order, you might cause troubles not only for your own logic, but also for all other modules that were expecting, as example, the window.TCPSocket to be there. Fix it dropping any UMD logic around your polyfill, and publish again ;-)