1) From the user perspective, the fact a given module is delivered through the "extensions manager" could be considered an "implementation details". If probably means that at the top of the page "Modules category" could remain as it is. We could also think about changing it into "Modules or Extensions cateogory"

2) After clicking on a category, the user would be able to see the associated module and click on the documentation of a given module.

3) The concept of "provenance" or "delivery mechanism" could be associated with a module. In case of a module belonging to an extension, it should be possible to click on the associated extension description page.

4) I also believe the list of modules display at the top of [1] should be generated automatically.

5) It should probably be possible to filter this list by module "provenance": "built-in" or "extensions"

[1] http://wiki.slicer.org/slicerWiki/index.php/Documentation/4.1

A key thing about extensions is making it clear to the user where the extension comes from. From that perspective there are two kinds:

Kind A: ones that the slicer developers offer as optional downloads, either because they are large or overly specialized

Kind B: ones that are provided and supported by third parties.

I like the idea of letting the B extensions leverage all our infrastructure but we need to make clear where users need to go with questions (and where to give credit).