The difference is polls are a plugin and the interface for plugins has a “disabled” property that is being used here.
I have been very clear in the API so far that disabled means “don’t initialize this plugin.” It’s a miracle it works with the current hack, and I’m pretty sure in the future it will suddenly break if we depend on this behaviour.
If we want admins to be able to create polls we have to add a new setting for it.
Aha, it is a plugin limitation. OK I can agree with adding the setting in that context @tgxworld . The other option is to make polls part of core but that would likely be more work.
It isn’t clear to me from Plugin::Instance’s
If the plugin author doesn’t call enabled_site_setting, the plugin is going to be enabled by default and disabling the plugin via the site setting will be handled by the author. There isn’t any hack I had to do in order to implement the feature. Right now, the only way to truly disable a plugin is actually to remove it if the plugin author doesn’t handle it. We will probably want to have some form of enforcement as to how enabling/disabling plugins is handled but I’ll leave that for another topic.
We need a method of globally disabling all plugins aka “safe mode” for 1.7… could this work be folded into that?
Ok I’ll take that once we start working on 1.7. 
Oh I see - in this case you weren’t using enabled_site_setting ? Because that’s the feature that allows a plugin to be intelligently enabled/disabled and was in fact what was I referring to.
If we’ve implemented the same behaviour without using those hooks it should be safe, although it’s a little surprising to me since it dodges our built in code that does a similar thing with a similar name.
I’m okay with it for now - but in the future if we migrate it to use enabled_site_setting it’s something we have to be aware of.