Why not remove RestExtension and MarkdownExtension from this list, and handle them like any other CompilerExtension should be? And add a helper function which takes care of DISABLED_PLUGINS?
I'll start a branch for that.

We are not breaking backwards compatibility here. You can certainly write a helper function, but leave the two classes alone.

Why is this breaking backwards compatibility?

My implementation: https://github.com/getnikola/nikola/compare/unifying-compiler-extensions?expand=1
I'm not sure how to actually use CompilerExtensions without changing the Rest and markdown compiler, except if activating a pluing multiple times is no problem for yapsy (haven't tested that). If I'm trying to use yapsy's is_activated (see http://yapsy.sourceforge.net/PluginInfo.html), I get an exception when the GistExtension plugin is processed:

Traceback (most recent call last):
  File "/usr/bin/nikola", line 9, in <module>
    load_entry_point('Nikola==7.5.1', 'console_scripts', 'nikola')()
  File "~/nikola/nikola/__main__.py", line 158, in main
    site = Nikola(**config)
  File "~/nikola/nikola/nikola.py", line 732, in __init__
    plugin_info.plugin_object.set_site(self)
  File "~/nikola/nikola/plugins/compile/rest/__init__.py", line 131, in set_site
    for plugin_info in site.activate_compiler_extensions('rest'):
  File "~/nikola/nikola/nikola.py", line 847, in activate_compiler_extensions
    print(plugin_info.is_activated)
  File "/usr/lib/python3.4/site-packages/yapsy/PluginInfo.py", line 193, in _getIsActivated
    return self.plugin_object.is_activated
AttributeError: 'GistExtension' object has no attribute 'is_activated'

In my solution, the new code would have to query Nikola/Compiler from the .plugin file, a field which I just added, to find out which extension plugins to activate for this compiler. Compiler plugins that do not have that field would crash Nikola if you did not catch the exception. Turns out plugin activation does pretty much nothing, so we could just talk to plugin_object anyway, which is guaranteed to have a compiler_name attribute.

I would rather put the function in CompilerExtension.activate_extensions (and not the site object, to make things cleaner) to be used by everyone.

is_activated should be handled by yapsy (in IPlugin.__init__), no idea why that does not happen here.

Please move activate_extensions to CompilerExtension (as there is no reason to put it in nikola.py) and create a pull request.

PS. I’m leaving the Nikola/Compiler field in, it could come in useful if we ever implement some category system on the plugins site.

Is yapsy offering a nice way to get to the contents of the parsed .plugin file? Then reading Nikola/Compiler would be easy.
So how do you want that activate_extensions of CompilerExtension be implemented? As a static method, called with site or site.compiler_extensions? Anyway, that doesn't really look clean to me. I'd rather put it into PageCompiler as a non-static method, because there it fits much better.

I actually meant to say PageCompiler, sorry. It does not make any sense in CompilerExtension, in fact.

To read Nikola/Compiler, you can use plugin_info.details.get('Nikoala', 'Compiler'), but it’s better if you didn’t — we can just talk to plugin_info.plugin_object.compiler_name without much trouble, which will spare us has_section and has_option checks and workarounds for old reST and Markdown extensions.

Ok, then we both agree on that :)

I also agree that we shouldn't use Nikola/Compiler yet. How about emitting a warning if Nikola/Compiler is not set? Or should we wait for v8 to do that (since right now, most page compilers in the open won't have it and it might confuse users)?

Let’s not even bother enforcing it, it’s not really useful for Nikola itself and will be used only for the plugin page.